> > > > > > They do, but the referenced "inner-thing" needs it's own reference > > count to > > > know how many "bytes-views" are sharing it. When a bytes-view gets > > cleaned > > > up, it decrefs the reference count of the inner-thing it is referring > > to, > > > and if the reference count goes to zero, the bytes-view calls the > > > destructor for the inner-thing. > > > > > Hm, I thought the 'inner-thing' is a python object (with it's own > > refcount) itself. Isn't the 'inner-thing' the bytes object owning > > the allocated memory? And the 'outer-things' (the views) simply > > viewing slices of this memory? > > > > The outer-thing is definitely the "bytes object", since that's what people > will work with directly. It has to be a true Python object in all its > glory. > > The inner-thing _could_ be a Python object (and Guido suggested that maybe > it should be), but that's an implementation detail. I don't know why > anyone would want to work with the inner-thing directly. However, one good > use case and I'll be sold on the idea. > > I'll definitely add some verbage to clarify this in the next revision. > I've quickly read the pep again. I see no mentioning of an 'inner object' and an 'outer object' there, so I would recommend you try to explain this (if you want to stay with this decision). OTOH, your 'inner thing' has a refcount, an (optional) destructor which is a kind of closure, instance variables (memory pointer, readonly flag), so there is not too much missing for a full python object. Could the 'inner thing' have the same type as the 'outer thing': the inner thing being a full view of itself, and the outer thing probably a view viewing only a slice of the inner thing? Thomas
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4