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. 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.
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.
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".
cb
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
