On Aug 19, 2008, at 10:59 AM, Chuck Blake wrote: > Hey, guys. Thanks for considering this. > > I can think of at least 3 use cases, though there may be more. > As with most language mechanisms (beyond a tiny core), one can > convert each use case into special higher level substitute that > can do a more complete job. There is also charm to just one > easy to implement/understand facility. > > 1) Idempotent inclusion (already described) > > cimport does not do everything. "cimport *" not working > is just one example unlikely to go away.
"cimport *" works right now. > Another would > be cross-file inline-ability of tiny little functions. > On those occasions when a user needs to 'include', it's > helpful to have protections against multiple inclusion > types of errors. I think we should rather support inline functions in .pxd files. Non- inline functions can be cimported. Includes should be much less used then the are now, but they have their place (when you actually want to textually include code in multiple places.) > > As per my original post, that the same "do once" behavior > can be achieved already through even uglier, lower level > compile-time state comparison: > > DEF FOO_1 = 1 > DEF FOO_2 = 1 > IF FOO_1 == FOO_2: > DEF FOO_2 = 2 > ... > Yes, this could be replaced with an "include_once" as per > Dag's reply, which is better since include-ees need no > indent. This is about as easy to implement as DEFINED. > > 2) Compile-time constant defaulting/overriding > > In client-module: # client knows objects in the B-tree > DEF M = 128 # are small and wants large branches > include "Btree.pxi" # to minimize TLB misses/latencies. > > In btree.pxi: # but the impl module can provide a > if not DEFINED M: # reasonable default definition > DEF M = 10 > int someArray[M] > > ( Please don't pick on my B-tree paramter example. If one accepts > that there is any utility to compile-time parameters, one can > surely make one's own e.g. where it is nice to override them. ) > > Yes, this could also be done with a "WEAKDEF" syntax that would > not overwrite an already defined DEF. That's probably about as > easy to implement as DEFINED. > > This general style of thing could also be done even better with > a smarter include: > defining_include "Btree.pxi" M=2, X=Y, ... > which could even scope DEFs of the parameters to the range of > the included text. This "parametrized file" form would involve > new semantics for any DEF'd name in include-ees as being "weak" > which is kind of subtle and is clearly quite a bit more work. I much prefer DEFINED to WEAKDEF. It's easier to understand and requires less language changes. > > 3) Compile-time function availability testing > > "enumerate" is currently available at compile-time, but "sorted" > and "reversed" are not. "oct" and "hex", but no "bin" (not in > python either...). Who can anticipate what Python and you guys > may want to add (or subtract!) from the builtin namespace? > It's nice to let developers phase in the dependence of their > code on new Cython versions. > > It's both simple and Pythonic to just query the namespace to see > if what you need is there, only here the queyr is at compile-time > rather than run-time. In that light, "has_key" or "HAS_KEY" may > be better than "DEFINED". I chose "DEFINED" to match the pattern > of "IF"/"DEF". "HAS_KEY" suggests HAS_KEY(COMPILE_ENV, > "mystring") > which needs two compile-time objects -- the function and dict. > > Finally, yes, a full compile-time meta-programming facility allowing > type inspection and such would be better. However, that requires > working out and implementing many details. It seems reasonable in > lieu of all that being done to just complete the IF/DEF system with > something simple like "DEFINED". Personally, I find the IF/DEF currently in the compiler to be ugly. However, given that they exist, throwing a DEFINED in there rounds out the options. I would *much* rather see a patch that lets distutils run a preprocesor (your choice of the C preprocessor or something more modern) rather than building more preprocessing into the language itself. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
