[Python-ideas] Re: Traits

2020-02-16 Thread Stephen J. Turnbull
Steven D'Aprano writes: > On Sun, Feb 16, 2020 at 06:08:54PM +0900, Stephen J. Turnbull wrote: > > Answering off-list by moderator request. > > Are you sure about that? :-) I'm not sure about much of anything these days. I know how to do it, I just didn't. :-( My apologies to all. Steve

[Python-ideas] Re: Traits

2020-02-16 Thread Steven D'Aprano
On Sun, Feb 16, 2020 at 06:08:54PM +0900, Stephen J. Turnbull wrote: > Answering off-list by moderator request. Are you sure about that? :-) -- Steven ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to

[Python-ideas] Re: Traits

2020-02-16 Thread Stephen J. Turnbull
Soni, Answering off-list by moderator request. Before I go on to respond to the details, let me start by saying I'm definitely beginning to understand why you like the Rust syntax for traits, and maybe even some feeling for the semantics, although they're not very well documented anywhere I

[Python-ideas] Re: Traits

2020-02-15 Thread C. Titus Brown
Hi folks, moderator here. I’m calling it for this discussion. No further discussion is called for, IMO, although I’m sure Brett and I would be happy to be overridden by private request. Stephen, thank for providing an excellent summary post on which to lay this thread to rest :) :) best,

[Python-ideas] Re: Traits

2020-02-15 Thread Stephen J. Turnbull
All: If you're not interested in the back and forth, read my parallel post with a different subject. Soni L. writes: > I'm just gonna say learn rust since you actively refuse to accept > my explanation of rust traits. don't reply again until you've > learned rust. OK, done. > you don't

[Python-ideas] Re: Traits

2020-02-15 Thread David Mertz
The OP's posts all seem to consist of: 1. This other thing is way better 2. I won't explain what it is, but Rust does it better 3. The other folks who have used Rust don't understand it either 4. You are all too dumb to understand this great thing 5. Python should change it's syntax to allow this

[Python-ideas] Re: Traits

2020-02-15 Thread Soni L.
On 2020-02-15 10:06 a.m., Paul Moore wrote: On Sat, 15 Feb 2020 at 12:17, Alex Walters wrote: > > Telling someone you are trying to convince to do something to go learn something else to "get on your level" as the youth would put it... is not how you get people to agree with you. > > To

[Python-ideas] Re: Traits

2020-02-15 Thread Paul Moore
On Sat, 15 Feb 2020 at 12:17, Alex Walters wrote: > > Telling someone you are trying to convince to do something to go learn > something else to "get on your level" as the youth would put it... is not how > you get people to agree with you. > > To summarize this thread, as I see it so far > > *

[Python-ideas] Re: Traits

2020-02-15 Thread Alex Walters
J. Turnbull > Cc: python-ideas@python.org > Subject: [Python-ideas] Re: Traits > > you don't want me to be rude but when I literally explain rust traits > you throw me an "that's not traits and fuck you for being rude/trying to > get me to think". > > I'm ju

[Python-ideas] Re: Traits

2020-02-15 Thread Chris Angelico
On Sat, Feb 15, 2020 at 10:39 PM Soni L. wrote: > > you don't want me to be rude but when I literally explain rust traits > you throw me an "that's not traits and fuck you for being rude/trying to > get me to think". > > I'm just gonna say learn rust since you actively refuse to accept my >

[Python-ideas] Re: Traits

2020-02-15 Thread Soni L.
you don't want me to be rude but when I literally explain rust traits you throw me an "that's not traits and fuck you for being rude/trying to get me to think". I'm just gonna say learn rust since you actively refuse to accept my explanation of rust traits. don't reply again until you've

[Python-ideas] Re: Traits

2020-02-15 Thread Stephen J. Turnbull
Soni L. writes: > On 2020-02-14 11:42 p.m., Steven D'Aprano wrote: > > On Fri, Feb 14, 2020 at 07:24:48PM -0300, Soni L. wrote: > I do suggest learning Rust, at least for the traits. That's inappropriate because it's placing responsibility on us to puzzle out what you mean, rather than on you

[Python-ideas] Re: Traits

2020-02-14 Thread Soni L.
On 2020-02-14 11:42 p.m., Steven D'Aprano wrote: On Fri, Feb 14, 2020 at 07:24:48PM -0300, Soni L. wrote: > In Rust, you can have: That's great for people who understand both Rust styntax and Rust semantics, but this is a Python discussion group, not Rust. We aren't all Rust experts. I do

[Python-ideas] Re: Traits

2020-02-14 Thread Steven D'Aprano
On Fri, Feb 14, 2020 at 07:24:48PM -0300, Soni L. wrote: > In Rust, you can have: That's great for people who understand both Rust styntax and Rust semantics, but this is a Python discussion group, not Rust. We aren't all Rust experts. > with strait, you can't have both Foo and Bar on Baz -

[Python-ideas] Re: Traits

2020-02-14 Thread Ethan Furman
On 02/14/2020 02:24 PM, Soni L. wrote:   class Foo(Trait):     def x(self):   raise NotImplementedError   class Bar(Trait):     def x(self):   raise NotImplementedError   class Baz(TraitObject):  # "mirrors" class Baz(object):     @impl(Foo)     class Foo:   def x(self):

[Python-ideas] Re: Traits

2020-02-14 Thread Chris Angelico
On Sat, Feb 15, 2020 at 9:25 AM Soni L. wrote: > the function explicitly calls the trait method on the object: > >obj = Baz(); >Bar(obj).x() # or Baz.Bar.x(obj) if you know the name under which > the trait impl is located and wanna use it rather than making a wrapper > trait object. And

[Python-ideas] Re: Traits

2020-02-14 Thread Soni L.
In Rust, you can have:   trait Foo {     fn x();   }   trait Bar {     fn x();   }   struct Baz {}   impl Foo for Baz {     fn x() {     }   }   impl Bar for Baz {     fn x() {     }   } with strait, you can't have both Foo and Bar on Baz - it just raises by default. if you don't want it

[Python-ideas] Re: Traits

2020-02-14 Thread Steven D'Aprano
On Fri, Feb 14, 2020 at 09:53:27AM -0300, Soni L. wrote: > Nobody has implemented actual > traits in Python yet, only mixins with extra steps That's a bold claim, since the meaning of "traits" you gave earlier in the thread sounded to me exactly like "mixins with extra steps". Michele

[Python-ideas] Re: Traits

2020-02-14 Thread Ethan Furman
On 02/14/2020 04:53 AM, Soni L. wrote: That's not traits. That's its own thing. That's not even mixins, it just seems to be type-checked attributes. Nobody has implemented actual traits in Python yet, only mixins with extra steps and there are 2 libraries providing these type-checked

[Python-ideas] Re: Traits

2020-02-14 Thread Soni L.
That's not traits. That's its own thing. That's not even mixins, it just seems to be type-checked attributes. Nobody has implemented actual traits in Python yet, only mixins with extra steps and there are 2 libraries providing these type-checked attributes and calling them "traits" for

[Python-ideas] Re: Traits

2020-02-14 Thread Neil Girdhar
You may be interested in the excellent traitlets library: https://traitlets.readthedocs.io/en/stable/ On Friday, February 7, 2020 at 11:11:59 AM UTC-5, Soni L. wrote: > > I'd like to see traits some day, with a syntax similar to this one: > > trait Trait: >def x(self): > raise

[Python-ideas] Re: Traits

2020-02-07 Thread Steven D'Aprano
On Fri, Feb 07, 2020 at 10:33:00AM -0600, Nick Timkovich wrote: > I assume traits are a feature of another language, but not being familiar > with it can you illustrate its need a bit better? Can you give an example > in current Python, and how it could be made more clear with the notional >

[Python-ideas] Re: Traits

2020-02-07 Thread Ethan Furman
On 02/07/2020 01:40 PM, Greg Ewing wrote: On 8/02/20 5:59 am, Soni L. wrote: Traits are an alternative to Multiple Inheritance. They solve the problem of name conflicts by making them an ambiguity error and requiring you to disambiguate (at call site). This sounds like something that

[Python-ideas] Re: Traits

2020-02-07 Thread Greg Ewing
On 8/02/20 5:59 am, Soni L. wrote: Traits are an alternative to Multiple Inheritance. They solve the problem of name conflicts by making them an ambiguity error and requiring you to disambiguate (at call site). This sounds like something that would work better in a statically typed language,

[Python-ideas] Re: Traits

2020-02-07 Thread Calvin Spealman
On Fri, Feb 7, 2020 at 12:02 PM Soni L. wrote: > > > > On 2020-02-07 1:33 p.m., Nick Timkovich wrote: > > On Fri, Feb 7, 2020 at 10:11 AM Soni L. wrote: >> >> I'd like to see traits some day, with a syntax similar to this one: >> ... >> if the trait isn't used in the function definition you get

[Python-ideas] Re: Traits

2020-02-07 Thread Mark Dickinson
Stéfane Fermigier wrote: > Note that there are several packages already in PyPI: > > https://pypi.org/project/traits/ > https://pypi.org/project/strait/ That first package is unrelated, I'm afraid: completely different meaning of the word "trait". In that case, a "trait" is an observable, typed

[Python-ideas] Re: Traits

2020-02-07 Thread Chris Angelico
On Sat, Feb 8, 2020 at 4:01 AM Soni L. wrote: > Hello Nick! > > Traits are an alternative to Multiple Inheritance. They solve the problem of > name conflicts by making them an ambiguity error and requiring you to > disambiguate (at call site). > Okay, that sounds like a good summary. I'm not

[Python-ideas] Re: Traits

2020-02-07 Thread Stéfane Fermigier
Best reference that I know of: "Traits: A Mechanism for Fine-grained Reuse" by: STEPHANE DUCASSE OSCAR NIERSTRASZ and NATHANAEL SCHARLI ROEL WUYTS ANDREW P. BLACK *Inheritance is well-known and accepted as a mechanism for reuse in object-oriented languages. Unfortunately, due to the coarse

[Python-ideas] Re: Traits

2020-02-07 Thread Soni L.
On 2020-02-07 1:33 p.m., Nick Timkovich wrote: On Fri, Feb 7, 2020 at 10:11 AM Soni L. > wrote: I'd like to see traits some day, with a syntax similar to this one: ... if the trait isn't used in the function definition you get the raw object,

[Python-ideas] Re: Traits

2020-02-07 Thread Nick Timkovich
On Fri, Feb 7, 2020 at 10:11 AM Soni L. wrote: > I'd like to see traits some day, with a syntax similar to this one: > ... > if the trait isn't used in the function definition you get the raw > object, where name conflicts between traits (but not between traits and > inherent methods) result in