4 ms·

Show HN: Rust-Like Traits in Python

50 points by xrudelis 5y ago

xrudelis 5y ago
This is an idea I had while thinking about how flexible Python inheritance is. I decided to turn it into a weekend project, and now it is my first open-source package. I hope someone finds it useful!
webmaven 5y ago
This reminds me of Python interfaces, which were inspired by Zope interfaces. Choosing among competing interfaces overriding the MRO was a runtime configuration option, often using adapters to wrap other objects. This turns out to be handy when implementing a CMS extended with 3rd-party plugins that aren't written with each other in mind. Fun times!
_dain_ 5y ago
I don't understand how this works: https://github.com/xrudelis/pytrait/blob/master/examples/basics.py https://github.com/xrudelis/pytrait/blob/master/examples/bas... The "Sheep" class never inherits from "Animal" or "ImplAnimalForSheep", nor does its body reference them in any way, so how does it get the "talk" method?
- aldanor 5y ago
  Some pretty horrible string / 'registry' metaclass hackery: https://github.com/xrudelis/pytrait/blob/master/pytrait/impl.py#L41 https://github.com/xrudelis/pytrait/blob/master/pytrait/impl...
  - xrudelis 5y ago
    That's right. The reason for this is that it's a lot of boilerplate if you were to require listing every relevant Impl block as a superclass of your struct. I also, as a bonus, like enforcing a consistent class naming style.
    - Diggsey 5y ago
      That's not a great reason to use strings to identify classes though... Why not just give `Impls` a special attribute: class ExampleImpl(Foo, metaclass=Impl): target = Bar Or do the entire thing via a decorator: @impl_for(Bar) class ExampleImpl(Foo): pass ?
      - xrudelis 5y ago
        I think these are all equally good. The Impl's name should never need to be referred to, so ultimately the choice should be based on what's easiest to read. EDIT: actually, your examples wouldn't work as-is, since it would result in circular references (something Python isn't well-equipped to handle). Your target names would need to be strings instead of the actual class. EDIT2: I have updated the code to allow for another syntax: class AnyImplNameIWant(MyTrait, metaclass=Impl, target="MyStruct"): ... It would certainly be nicer if `MyStruct` didn't need to be a string of course. I really think these options are mostly down to taste, so I'll just have to trust that this alternative reads sufficiently more nicely.
        aldanor 5y ago
        Correction: what's easiest to read to someone who hasn't carefully read every single line of your library. Verbosity is not always bad, if it yields clarity.
      - luoc 5y ago
        I'd go for the decorator approach for its explicitness. It reads like plain English without having a deeper understanding of the concepts. Also, it does not pollute the implementors namespace. Even if one argues for the naming convention solution, one has to admit that it causes confusion for most people stumbling over it for the first time.
    - OJFord 5y ago
      Why not use a decorator for that? @impl(Sheep, Animal) class ImplAnimalForSheep: ... or something? It probably needn't even be a separate class - just decorate the relevant methods (or the `Sheep` class itself) `@impl(Animal)` and check the necessary ones are implemented on instantiation.
- homarp 5y ago
  it's the naming convention that does it. "Impls have a strict naming convention, like ImplMyTraitForMyStruct. This is used to automate the list of implementations for MyStruct; you don't need to explicitly list any superclasses of MyStruct, just based on the Impl name it will inherit from all relevant Impls."
miohtama 5y ago
Something that fills the same need as traits have been available for Python in the form of zope.component architecture for some decades now https://zopecomponent.readthedocs.io/en/latest/narr.html https://zopecomponent.readthedocs.io/en/latest/narr.html However in the end abstract base classes and class decorators take you a long way. zope.component power is only useful for complex frameworks like Plone CMS and Pyramid.
orf 5y ago
How does this differ in practice from typing.Protocol?
- xrudelis 5y ago
  It looks to me like the goals with typing.Protocol are for static type checking. Whereas this module is intended both for interfaces (much like ABCs) and implementation re-use (see Rust's "blanket implementations"). These Traits could definitely be used in type annotation, and maybe there's a way to use typing.Protocol with them to aid static type checking in Python. I haven't tried static type checking in Python yet, but it sounds promising!
  - heavyset_go 5y ago
    > Whereas this module is intended both for interfaces (much like ABCs) and implementation re-use (see Rust's "blanket implementations") That's the role typing.Protocol plays, as well. Protocols are like ABCs, but using structural typing.
  - BerislavLopac 5y ago
    Protocols can be used for runtime checks (isinstance), even for classes that are not explicitly annotated with them - that's the main point of structural subtyping.
CornCobs 5y ago
I don't really understand the purpose of abstract base classes and interfaces in Python. Doesn't duck typing mean you are only interested in the concrete implementation?
- smitty1e 5y ago
  Just so. Yet, if there is interest in adding enough information to classes to support compile-time enforcement of interface requirements, ABCs to the rescue!
  - BerislavLopac 5y ago
    The beauty of Python is that it supports both nominal subtyping (class hierarchies) and structural subtyping (protocols).
  - actuallyalys 5y ago
    To clarify, mypy already has compile-time (well, static checker-time) enforcement of protocols (https://mypy.readthedocs.io/en/stable/protocols.html https://mypy.readthedocs.io/en/stable/protocols.html) and ABCs (https://mypy.readthedocs.io/en/stable/class_basics.html#abstract-base-classes-and-multiple-inheritance https://mypy.readthedocs.io/en/stable/class_basics.html#abst...). Maybe that's what you meant? The first time I read your comment I interpreted as "if there is interest [on the part of core Python developers]".
deleted 5y ago
[deleted]
tgz 5y ago
If you want Traits like in Rust, Result like in Rust, Option like in Rust, then just use Rust.

50 points by xrudelis 5y ago

This is an idea I had while thinking about how flexible Python inheritance is. I decided to turn it into a weekend project, and now it is my first open-source package. I hope someone finds it useful!

webmaven 5y ago

This reminds me of Python interfaces, which were inspired by Zope interfaces. Choosing among competing interfaces overriding the MRO was a runtime configuration option, often using adapters to wrap other objects. This turns out to be handy when implementing a CMS extended with 3rd-party plugins that aren't written with each other in mind. Fun times!

_dain_ 5y ago

I don't understand how this works: https://github.com/xrudelis/pytrait/blob/master/examples/basics.py https://github.com/xrudelis/pytrait/blob/master/examples/bas... The "Sheep" class never inherits from "Animal" or "ImplAnimalForSheep", nor does its body reference them in any way, so how does it get the "talk" method?

aldanor 5y ago
Some pretty horrible string / 'registry' metaclass hackery: https://github.com/xrudelis/pytrait/blob/master/pytrait/impl.py#L41 https://github.com/xrudelis/pytrait/blob/master/pytrait/impl...
- xrudelis 5y ago
  That's right. The reason for this is that it's a lot of boilerplate if you were to require listing every relevant Impl block as a superclass of your struct. I also, as a bonus, like enforcing a consistent class naming style.
  - Diggsey 5y ago
    That's not a great reason to use strings to identify classes though... Why not just give `Impls` a special attribute: class ExampleImpl(Foo, metaclass=Impl): target = Bar Or do the entire thing via a decorator: @impl_for(Bar) class ExampleImpl(Foo): pass ?
    - xrudelis 5y ago
      I think these are all equally good. The Impl's name should never need to be referred to, so ultimately the choice should be based on what's easiest to read. EDIT: actually, your examples wouldn't work as-is, since it would result in circular references (something Python isn't well-equipped to handle). Your target names would need to be strings instead of the actual class. EDIT2: I have updated the code to allow for another syntax: class AnyImplNameIWant(MyTrait, metaclass=Impl, target="MyStruct"): ... It would certainly be nicer if `MyStruct` didn't need to be a string of course. I really think these options are mostly down to taste, so I'll just have to trust that this alternative reads sufficiently more nicely.
      - aldanor 5y ago
        Correction: what's easiest to read to someone who hasn't carefully read every single line of your library. Verbosity is not always bad, if it yields clarity.
    - luoc 5y ago
      I'd go for the decorator approach for its explicitness. It reads like plain English without having a deeper understanding of the concepts. Also, it does not pollute the implementors namespace. Even if one argues for the naming convention solution, one has to admit that it causes confusion for most people stumbling over it for the first time.
  - OJFord 5y ago
    Why not use a decorator for that? @impl(Sheep, Animal) class ImplAnimalForSheep: ... or something? It probably needn't even be a separate class - just decorate the relevant methods (or the `Sheep` class itself) `@impl(Animal)` and check the necessary ones are implemented on instantiation.
homarp 5y ago
it's the naming convention that does it. "Impls have a strict naming convention, like ImplMyTraitForMyStruct. This is used to automate the list of implementations for MyStruct; you don't need to explicitly list any superclasses of MyStruct, just based on the Impl name it will inherit from all relevant Impls."

miohtama 5y ago

Something that fills the same need as traits have been available for Python in the form of zope.component architecture for some decades now https://zopecomponent.readthedocs.io/en/latest/narr.html https://zopecomponent.readthedocs.io/en/latest/narr.html However in the end abstract base classes and class decorators take you a long way. zope.component power is only useful for complex frameworks like Plone CMS and Pyramid.

orf 5y ago

How does this differ in practice from typing.Protocol?

xrudelis 5y ago
It looks to me like the goals with typing.Protocol are for static type checking. Whereas this module is intended both for interfaces (much like ABCs) and implementation re-use (see Rust's "blanket implementations"). These Traits could definitely be used in type annotation, and maybe there's a way to use typing.Protocol with them to aid static type checking in Python. I haven't tried static type checking in Python yet, but it sounds promising!
- heavyset_go 5y ago
  > Whereas this module is intended both for interfaces (much like ABCs) and implementation re-use (see Rust's "blanket implementations") That's the role typing.Protocol plays, as well. Protocols are like ABCs, but using structural typing.
- BerislavLopac 5y ago
  Protocols can be used for runtime checks (isinstance), even for classes that are not explicitly annotated with them - that's the main point of structural subtyping.

CornCobs 5y ago

I don't really understand the purpose of abstract base classes and interfaces in Python. Doesn't duck typing mean you are only interested in the concrete implementation?

smitty1e 5y ago
Just so. Yet, if there is interest in adding enough information to classes to support compile-time enforcement of interface requirements, ABCs to the rescue!
- BerislavLopac 5y ago
  The beauty of Python is that it supports both nominal subtyping (class hierarchies) and structural subtyping (protocols).
- actuallyalys 5y ago
  To clarify, mypy already has compile-time (well, static checker-time) enforcement of protocols (https://mypy.readthedocs.io/en/stable/protocols.html https://mypy.readthedocs.io/en/stable/protocols.html) and ABCs (https://mypy.readthedocs.io/en/stable/class_basics.html#abstract-base-classes-and-multiple-inheritance https://mypy.readthedocs.io/en/stable/class_basics.html#abst...). Maybe that's what you meant? The first time I read your comment I interpreted as "if there is interest [on the part of core Python developers]".

deleted 5y ago

[deleted]

tgz 5y ago

If you want Traits like in Rust, Result like in Rust, Option like in Rust, then just use Rust.