`Path` cannot add or init integers, only strings and other Paths about nbtlib HOT 2 CLOSED

The idea is that path objects and strings representing path objects should be interchangeable. When you instantiate or concatenate a path with a string, the string represents a full nbt path, not an individual key, the string actually gets parsed into a path object. But when you index into a path you extend it by an individual key. That's why you can use numbers too, the string you use to subscript is a key. Path + str and Path[str] are not equivalent.

>>> Path("a.b") + Path("c.d")
Path('a.b.c.d')
>>> Path("a.b") + "c.d"
Path('a.b.c.d')
>>> Path("a.b")["c.d"]
Path('a.b."c.d"')

To me it makes sense to keep the meaning clear. We can magically make it work like you suggested but it will lead to inconsistencies.

from nbtlib.

I really *love Path's design and features, it's undoubtedly one of the most amazing features of nbtlib. But I don't see by your example and explanation why wouldn't int fit that design or create any inconsistency.

If I understood correctly, the design principles you mentioned are:

• Path(x) constructor takes a full NBT path x, represented by a string or Path.
• path + x extends a path by concatenating it with another full NBT path x, represented by a string or Path.
• path[x] indexing appends a single key (or index) x, represented by a string (or int)

Is that correct?

• What about indexing using another full NBT path? Currently we have Path("a.b")[Path("c.d")] == Path("a.b.c.d"). But anyway, that's not my point.

My question is: what inconsistency would emerge from allowing an int, say 1, to be treated like "[1]"? Sure, an int is only able to represent a single component, and always an index (not a key). So what? That's a limitation of int, and Path shouldn't care. Just like any single component is accepted as a full path, be it "a", "[1]", or even "", so could an int.

My proposal is to handle integers the same way you handle "[x]", no more, no less. You can even convert 1 to "[1]" upfront in __new__, __add__ and __radd__, and let it be parsed as a string.

I believe such approach would not break the API in any way, nor create any inconsistency. The key here (no pun intended) is that an int is always an index

from nbtlib.