Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Using attrs in pystac object definitions #1153

Open
jsignell opened this issue Jun 7, 2023 · 0 comments
Open

[RFC] Using attrs in pystac object definitions #1153

jsignell opened this issue Jun 7, 2023 · 0 comments
Milestone

Comments

@jsignell
Copy link
Member

jsignell commented Jun 7, 2023

tl;dr the "subclass from dict" approach is more promising.

I just took a crack at using attrs to create pystac objects and wanted to write up some initial thoughts comparing that approach to the "subclass from dict" approach.

There are 3 main types of things stored on pystac objects:

  1. data in pre-defined fields
  2. data in arbitrary fields
  3. other objects that aren't part of the spec, but are useful to have around (validator, reader)

The "subclass from dict" approach is very good at 2 and 3, but is less good at 1
The attrs approach is very good at 1, not good at 2 and ok at 3.

So I was originally thinking maybe we can do both! Subclass from dict and extend it using attrs. But that doesn't really work because one of the main things that attrs wants to do is write the __init__.

My main finding is that attrs feels like a nice way to implement a data model, but if we are trying to store other non-spec attributes on the class (I'm looking at things like _stac_io) it starts to be less nice.

Pros:

  • data model is the primary feature of the class
  • equality, repr, serialization are all included

Cons:

  • any attribute on the class that should not be serialized needs to be explicitly excluded (or be private)
  • there are some extra hoops to jump through for generic fields
@gadomski gadomski added this to the v2.0 milestone Sep 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants