[pypy-dev] Objects and types in the stdobjspace
Armin Rigo
arigo at tunes.org
Tue Jun 10 16:30:27 MEST 2003
Hello Holger,
On Tue, Jun 10, 2003 at 04:03:00PM +0200, holger krekel wrote:
> Though i somewhat (*) agree i also think that intermingling function definitions
> and function executions is ugly, too. Does it make sense to at least move
> the register calls to the end of the file, then? Usually the func name
> and the argument names make it human-understandable enough which
> type-implementations a function is supposed to handle.
This last point is actually another problem by itself, because we all tend to
forget the register() stuff after we wrote the function definition. If the
register() calls are to be moved at the end of the file it will not help.
Somehow I find that the closer this information is to the function definition,
the better; even just after the body is somehow not close enough, hence the
search for header-based alternatives.
The suggestion pointed out by Paul:
def any_list_extend(space, w_list, w_otherlist):
assert isinstance(w_list, W_ANY)
assert isinstance(w_otherlist, W_ANY)
return space.inplace_add(w_list, w_otherlist)
is closer to this goal, and hopefully "natural" enough to avoid type
declaration flame war. When I wrote the example this one is based on I forgot
that the multimethod we want to register to should be mentioned somewhere as
well -- but where ? If that's in the function name, we are back to naming
conventions. I'm not convinced about naming convention, but well, just for the
comparison:
def getitem__ListObject_SliceObject(space, w_list, w_slice):
...
def list_append__ListObject_object(space, w_list, w_obj):
...
Why not.
Armin
More information about the pypy-dev
mailing list