> 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). Of course, we'd still have several sets of macros, because of the need to be able to say different things: allocate and initialize an object, initialize an object, deinitialize an object and free its memory, deinitialize an object without freeing its memory; and the GC variations of all these; and macros that take type arguments used for convenient casting. (Initializing and deinitializing an object are things like setting the refcount to 1 and initializing the type pointer, but various debugging modes add functionalities like counting allocations and linking all objects together in a doubly-linked list.) > > 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. Assuming we're ready to start over, I'd like to see a minimal proposal so we can discuss something concrete. --Guido van Rossum (home page: http://www.python.org/~guido/)
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