Rodrigo Silva

> There's another type of feedback I got a few times over the years, and it's that the wrappers are annoying, especially for beginners. They expect to be able to...

> > If one can't use wheels (why?), it will build from source, what's the problem? > > so if there aren't pre-built binaries available for them they won't be...

> I kinda lose confidence in code the longer it sits around unattended and since the core of the library is now a few years old I'm really itching to...

> > msgpack is awesome > > Haha yeah sometimes I kind of wish Mojang wasn't stuck with nbt too! Minecraft is, but I'm not ;-) I'm planning on using...

> So another thing I'm thinking about for improving `.parse()` performance is making unpacking (and byteswaps) lazy and using memoryviews to track the position of each tag in the original...

I suggest 2 possible approaches: - `Path.from_parts()`, classmethod that takes a plain tuple* and builds the accessors without invoking the parser, assuming each part is a _single_, **non-empty** component -...

> but `_tree.get_element(Path(), ["foo.bar", 2, "spam"])` would result in `foo.bar[2].spam` instead of `"foo.bar"[2].spam`. It's the kind of subtle error I was thinking about the other day. Yeah, but since it...

in this scenario, `[]` _indexing_ (not _slicing_) is a low-level tool too, as it also skips the parser by contract, assuming the index is always a single element for _leaf_...

> Anyway, I agree that `from_parts()` would be pretty useful. You could probably currently implement it yourself with something like this (untested): > > ```python > path = tuple.__new__(Path, (NamedKey(k)...

> Yup sorry if this wasn't really clear, the first paragraph wasn't really related to `from_parts()` or anything. It was just a tangent [...] Nah, you were clear enough I...