[pypy-dev] Objects and types in the stdobjspace

[holger krekel]

Hello Armin,

[Armin Rigo Tue, Jun 10, 2003 at 03:43:53PM +0200]
> Hello Holger,
> 
> On Tue, Jun 10, 2003 at 03:26:36PM +0200, holger krekel wrote:
> > I was thinking more along these lines ...
> > 
> >     def list_extend__any_any(space, w_list, w_otherlist):
> >         return space.inplace_add(w_list, w_otherlist)
> 
> Yes, I know, this is the kind of naming magic which I really dislike I must
> say. It's fine for 'any' which is a bit special anyway, but it starts to be
> messy when substrings of the name must be converted into classes that might be
> in other modules, or multimethod objects you'd like to register to, etc...
> 
> I'd very reluctantly admit that you could require that the relevant classes
> and multimethods are to be present in the current module's globals (thus
> forcing the use of 'from xxx import classes'), and will be searched only here.  
> Still I don't like that. My moto is that forced naming conventions are bad,
> and direct references to the objects you're interested in are good.

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. 

cheers,

    holger


(*) forgetting about all the special __ names ...
    these names serve a similar goal which is to hook 
    their associated methods into the python object machinery
    (i.e. __init__, __getattr__, __call__, ...). My proposed '__' 
    part of the function name was meant to "remind" of this.