On Fri, 15 Mar 2002, Tim Peters wrote: >[Guido] >> ... >> I think what's documented is of little value here given that few >> people bother to read it, and most people instead read the source. :-( > >Heh. That gets me back to where I landed many months ago: because people >*do* rely on what the code has actually done, and what the code has actually >done is expand to platform "malloc" and "free", the only truly safe way to >start using pymalloc is to map all the existing macros to malloc and free >directly, and change the core to use a new API (which motivated extension >authors would be welcome to use too, provided they agreed to believe the new >API's docs <wink>). I expect a much simpler API would be possible if it >were YAGNI-free -- even the very old distinction between "plain memory" and >"object memory" has proved to be a YAGNI (worse, is actively getting in the >way now). > >> ... >> Tim, do you think you're ready to make a specific proposal? > >No, and until we make up our minds about whether to start over, it's really >two or three different proposals. One advantage of starting over is that it makes the compile time option to complain about incorrect usage much easier to implement -- just complain about anything using the old names. /Paul
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