[Tim] >> but the crucial phrase "the same memory API family" is left undefined. [martin@v.loewis.de] > I always thought the notion of a "memory API family" is fairly obvious > - none of those families has more than three members. How do you know? The phrase simply isn't defined. "Fairly obvious" isn't reference-doc quality, and I clearly disagreed the first time around that "it's obvious". That means it isn't <wink>. > There is always one for allocation and one for deallocation, and > perhaps one for reallocation. That's it. Perhaps. >> Like, are the functions and macros interchangeable? > Of course not. You use the macros for efficiency, accepting that you > incorporate the implementation in your code, which results in a > depenency between the binary extension module and the binary Python > installation. I wasn't talking about efficiency or binary compatibility, just about what (exactly) constitutes "same memory API family" (which, BTW, belongs in the reference docs proper, not in the middle of a page of examples). >> For example, if you know something was allocated via PyMem_Malloc, >> is it OK to release it via PyMem_FREE? I simply can't guess from >> what the docs say, again because what constitutes "a family" is left >> undefined. > If you buy the notion of memory API families, I'd be delighted to, if the concept were spelled out. > you cannot deallocate the things this way. > ... > Of course, you will get away with mixing the macro and non-macro > versions, at least if you are not crossing Python version boundaries. > Do that and you are on your own, though (if desired, Python could > easily guarantee that you can mix APIs in this way, but I see no need > for that guarantee). I see nothing in the docs either forbidding or allowing such mixture; your view relies on the personal understanding of "memory API family" you've fought your way to after making a focused study of the source code. Extension authors aren't so conscientious, although I expect some have picked up by now that all the macro forms have been "deprecated" outside the core. > ... If I can get the TeX to create a table for me, I'll see whether > I can produce a table. More likely, Fred will have to fix it... That would be great. Fred can do this from a plain text table with ease -- wrestling with TeX shouldn't stand in the way. >> The endless layers of indirection macros make this quite a pain > I'm also uncomfortable with those. Fortunately, the family of the > "object allocator" does not deserve being documented - I doubt anybody > will ever need this. Also, the overriding hooks for replacing the > function names and signatures don't need to be documented. Agreed. >> Which API? > PyObject_MALLOC/REALLOC/FREE, and PyCore_* (both object and raw). Gotcha. >> In the Python source, the thread implementations use malloc and free >> on purpose, but it also turns up a curious > > > > free((char *)Py_FileSystemDefaultEncoding); > [...] >> Does that mean that, on Windows, we may free() a static char*?! > Of course not. This is wrapped in > > #if defined(HAVE_LANGINFO_H) && defined(CODESET) > > neither of which is defined on Windows. As I said, it's worthy of a comment. *I* have no idea whether HAVE_LANGINFO_H and/or CODESET are defined on Windows. If the correctness of this code *relies* on that they're not defined on Windows (as it still appears it does), an "#if Windows ... #error" would even be appropriate.
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