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

_make is part of namedtuple's contract, not tuple #72

Open
marksteward opened this issue Mar 5, 2021 · 2 comments
Open

_make is part of namedtuple's contract, not tuple #72

marksteward opened this issue Mar 5, 2021 · 2 comments

Comments

@marksteward
Copy link

marksteward commented Mar 5, 2021

I think these should read namedtuple:

https://github.com/Infinidat/munch/blob/d0aeb06/munch/__init__.py#L461
https://github.com/Infinidat/munch/blob/d0aeb06/munch/__init__.py#L523

Currently, if a custom class inherits from tuple and an instance ends up with a _make attribute, munch will call it when the __dict__ attribute is accessed. Unlikely to happen by chance, but munch also inserts itself into SafeLoader, so it should probably err on the defensive side.

@marksteward
Copy link
Author

Apparently there's no easy way to detect namedtuples other than existence of these not-quite-magic methods. This feels like a footgun, but I'm not sure how to fix it now.

@dangillet
Copy link

From https://bugs.python.org/issue7796, it seems that the "easiest" way to check if we're dealing with a namedtuple is to check that the type is tuple and that it has a _fields attribute.

Also see this answer from A. Martelli on SO: https://stackoverflow.com/a/2166841

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