Include the line number of the class declaration in binding keys #62
Conversation
Previously, we were using only the class name and filename as the binding key, which caused collisions if the same name was used to declare more than one (local) class in the same file (as in test_registry_attrs.py). In the process, this simplifies the process of getting the stack frames: we had been retrieving the same frames (redundantly) in two different ways in the process of defining a field, but the potential sharing was somewhat obscured because the code was split into very short functions. Fixes #43.
|
I think we should just fix that test - it seems like a bug anyways to have two classes with the same name. I'm not sure we need to include the line number, but I suppose it doesn't hurt. |
Also expand testing matrix to include more Python versions. Python 3.8 has slightly different inspect.stack behavior from both 3.7 and 3.10, and given those differences we should probably be testing at least one of each minor release version.
Having two classes with the same name isn't a bug: each class is defined within the scope of a function, so they really are distinct classes (with different class IDs), and they don't collide. This also applies to nested classes, in which the inner class might have the same reported function name as the outer class (
If we could assume that every class with |
|
Added a minor version bump and a |
|
Merging as v1.1.1. |
Previously, we were using only the class name and filename as the binding key, which caused collisions if the same name was used to declare more than one (local) class in the same file (as in test_registry_attrs.py).
In the process, this simplifies the process of getting the stack frames: we had been retrieving the same frames (redundantly) in two different ways in the process of defining a field, but the potential sharing was somewhat obscured because the code was split into very short functions.
Fixes #43.