Skip to content

DeepCollection()._obj not documented #6

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

Open
BenjaminEchelmeier opened this issue Jan 20, 2023 · 1 comment
Open

DeepCollection()._obj not documented #6

BenjaminEchelmeier opened this issue Jan 20, 2023 · 1 comment

Comments

@BenjaminEchelmeier
Copy link

Looking at the README, I wasn't able to find this for a refresh--it's a handy attribute that should probably be clear from the get-go.

@nixjdm
Copy link
Member

nixjdm commented Jan 20, 2023

I can mention it. There should be some qualifications with it's usage, because I'd think most of the time it isn't needed because:

  1. the DeepCollection object is a bona fide instance of the same type as _obj, so it should behave the same except where functionality is overridden
  2. default usage of a dc object should still match what would have happened with _obj. E.g. you'll still get a KeyError or IndexError if you supply a single key to __getitem__, most of the time.

There is some flexibility in 2 though, so it may be simpler to use _obj if you really want those errors to pop up, and don't want to think about how to achieve that with a dc. That will of course mean you can't supply a path, but that's simpler than getting a [path] to return an error. I realize now that I haven't made strict be a kwarg on DeepCollection, so I'll add that.

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