On 2020-02-10 2:03 a.m., Anders Hovmöller wrote:
> On 10 Feb 2020, at 04:18, Soni L. <fakedme...@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.)
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/WIPNTWZKUFD2WBBXHC6OQQY36YADN2S6/
Code of Conduct: http://python.org/psf/codeofconduct/
