On 2020-02-10 2:03 a.m., Anders Hovmöller wrote:
On 10 Feb 2020, at 04:18, Soni L. <fakedme+py@gmail.com> wrote:
Traits are composition tho. I think you missed something I said.
In that case I think we all missed it and then isn't that on you? Remember it is you who are trying to convince the list so any information missed or misunderstood is your problem :)
Again: an example that we can understand would help.
I am trying to implement a Rust-inspired trait system in pure python. part of what makes Rust so great is that you can have your type implement the whole stdlib of traits (which you wouldn't, but I digress), because traits effectively act like namespaces. and one of the key aspects of that is that you disambiguate at *call* site. the existing "trait" libs I've looked at were more like mixins, requiring you to disambiguate at *definition* site, which means there's no namespacing and you basically just have to hope the "traits" you picked have API-compatible methods/names/etc. for context, here's what some libs look like: - "traits" is strictly about type-checked attributes/properties. it never touches calling functions with those objects, or interacting with those objects directly (or rather, it does, but it's still more of a mixin kinda thing.) - "py3traits" is also mixin-like, with some ECS-like properties. still doesn't touch the issue of name/attribute ambiguities. - "strait" comes extremely close(!), which is nice, but it falls short by making the composability a runtime error when hitting name conflicts. "if traits T1 and T2 have names in common, enhancing a class both with T1 and T2 raises an error;" is explicitly the *opposite* of what I want. it also relies on you calling trait methods on the object itself, which leads to all the issues raised by mixins - especially if the class shadows a name defined by a trait. "strait" is promising but the author's tradeoffs have turned it into, basically, mixins with extra steps. and it just keeps going like that. searching for "traits" on pypi those are the 3 main packages, and then there are a bunch of packages that use them. but it is all effectively mixins. or runtime typechecking I guess. (fwiw, my take on python traits is rather duck-typed and you can make an object fit the trait model without going through the Trait or TraitObject classes or using @impl, but I digress.) I just find it kinda... I wouldn't say "sad", but something like it, that nobody has made it so you can explicitly call a trait method regardless of "names in common" either between 2 (or more) traits or between traits and the class that implements them. and yes, this does require a somewhat typed system, such as defining types and wrapping objects in the function signature, but you can still have a duck-typed trait system. (nothing prevents you from taking an arbitrary object and setting obj._traits_={MyTrait: something} on it (other than __slots__). I consider this duck-typing.)