Re: [boost] py_cpp review (try again)

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-11 10:56:47

Sorry about that last message; a slip of the keystroke caused it.

----- Original Message -----
From: "Gary Powell" <Gary.Powell_at_[hidden]>

> > I don't think there's a rigid official definition of the concept, but
does
> > it matter? After all, the function is just used to quickly filter out
> > names
> > we don't care about.
> >
> If that is the case, add one more char test that enforces
> "__?__" where "?" must be a non "_" non null character. All
> other forms won't match. The point of the complaint was that
> you weren't eliminating all of the bogus inputs before doing
> your search.

Python users are not supposed to touch names that begin and end with
double-underscores unless they are officially sanctioned special member
names. The Python documentation is (typically) vague in this area, but in
the community it is "well known Python lore" at least. The docs say:

2.3.2 Reserved classes of identifiers
Certain classes of identifiers (besides keywords) have special meanings.
These are:
Form   Meaning
_*     Not imported by "from module import *"(1)
__*__  System-defined name
__*    Class-private name mangling

I guess the actual meaning of '*' above is open to argument, but ultimately
the only "non-bogus inputs" are the ones that match the table. This is a
quickie bypass so I don't waste too many cycles on non-special-names.

> BTW. How come you added an optimization for early elimination, but are
> against an optimized search? Either it matters or it doesn't.

I always say "don't optimize prematurely" but in fact I don't always live
strictly by
that rule. Maybe I'm wrong here, but this seems like a good place to live by
my instincts. My instincts tell me that the binary search might be slower
than the linear one on a small table, and that I buy myself a little
insurance against adverse effects of the linear search by eliminating it for
nearly all names. Reading back what I've just written, this doesn't sound
like "my style". Maybe I've just been reading too much Python source code
(it's full of little tricks like this - I don't know if the writers measured
the effects or not).

-Dave