-
Notifications
You must be signed in to change notification settings - Fork 64
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
Inconsistent behaviour between attributes/keys after release 22.1.0 #233
Comments
Thanks for finding that, and sorry we broke your library! This corner case wasn't covered in our tests (Path behavior on an object where both [] and . are valid). There isn't any obvious reason for the change in behavior in the changes for this release. I think your hunch is correct -- the behavior of strings is that they will try There's two fixes if you want to keep using the new version without waiting for us: 1- Use Just for additional information, do you have any of the stack traces handy? (If the underlying error is KeyError "primarykey" that confirms the root cause is |
Hi @kurtbrose, sorry about my delayed response. I was trying to get more details. Thanks to your comments, I have simplified my example above. You are correct, when accessing the error is
However I don't think that is the problem. My code started failing because the precedence between key and attribute has changed for assign (as shown by the following traceback).
In my code, I was consistently using key based access (so And thank you so much for suggesting the two possible fixes in case it takes a while to resolve this in |
Thanks, I missed that it was the assignment target that was failing. That makes a lot more sense because we DID touch that code this release. (we added |
Thanks for the simplified reproduction, I was able to grab it pretty directly into a test. I've tried running the test against different releases, all the way back to 18.4.0 and they all fail in the same place. # access
assert schema.primary_key == []
> assert glom(schema, "primary_key") == [] # fails with KeyError
glom\test\test_regressions.py:26:
# ... snip out a bunch of glom internal lines ...
except Exception as e:
> raise PathAccessError(e, Path(_t), i // 2)
E glom.core.PathAccessError: could not access 'primary_key', part 0 of Path('primary_key'), got error: KeyError('primary_key')
glom\core.py:894: PathAccessError Maybe the version you were using was older than that? |
I think my description of the issue hasn't been very clear, my fault. I'll try to be clearer. Since a from frictionless import Schema
from glom import glom, Assign
fields = [
{"name": "id", "type": "number"},
{"name": "foo", "type": "datetime"},
{"name": "bar", "type": "string"},
{"name": "baz", "type": "boolean"},
]
schema = Schema(fields=fields, missing_values="NA")
# expected
try:
assert schema["primaryKey"]
except KeyError:
pass
# expected
try:
assert glom(schema, "primaryKey")
except KeyError:
pass The above works as expected (older versions, and latest release). However assignment used to work with 20.11, but doesn't work with 22.1. schema["primaryKey"] = "foo"
assert schema["primaryKey"] == "foo"
glom(schema, Assign("primaryKey", "id")) # AttributeError with 22.1
assert schema["primaryKey"] == "id" While investigating the above, I realised the following also fails (for all versions) and included it in my minimal example. glom(schema, "primary_key") # KeyError for both versions However thanks to your first comment I see it is unsurprising, and maybe even expected, as |
I use
glom
with a library calledfrictionless
. It's a library that manages metadata for datasets based on the frictionless specification.When using release 22.1.0, I see inconsistent behaviour between attributes/keys. Most (all?) of the metadata classes in
frictionless
are subclasses ofdict
. I have a hunch, the inconsistent behaviour is because of that.Here's a minimal example using the
Schema
class fromfrictionless
. I have put comments next to indicate expected behaviour, or to comment on the error.Edit: I simplified the examples
The text was updated successfully, but these errors were encountered: