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.
This is going to be interesting :-) Yes, most of the usecases I can see better higher-level constructs for (which I'll list briefly below for completeness, without making those the core message of this post I hope). However, you are very right in saying that this provides a solution *now*, not later. It can always be deprecated in some years. However, note that another option is using other macro languages (like m4; or something more modern) to preprocess your Cython files for the same result. This will give you all the power you wish for and more. On the one hand, your patch is already there. On the other hand, C++ meta-programming-through-templates stands as a permanent warning about the dangers of introducing too powerful low-level concepts rather than the appropriate high-level one :-) (I'm still about +0 for this). > 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. Personally I'd like to get rid of any need for include -- it's the kind of thing that lower-level languages keep around and higher-level languages avoid. I would very much like to implement inlineable code in pxd files (and I am about halfway there, but it's not a priority and I'll have much less time for Cython now after summer). > 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. ) No, I think it was an excellent example. We've touched upon both C++-style templates (not likely to come) and a "assumptions" language feature that would give you this thing but as a higher-level concept. This stuff is kind of needed for SciPy people to be able to use Cython for writing library utilities working for multiple data types. So both a quick fix now and a higher level concept later is likely to be welcome for them. (OTOH, they are currently using a preprocessor technique with C to do this, so they could likely just use the same preprocessor for their Cython code until something proper is in place.) -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
