>Although a function might imply that include is not a keyword. Maybe
> include "theinc.pxi" DEF A=1, ...
Yeah. That's not a bad syntax, either. It would be nice to have this
kind of local scoping of compile-time constants/parameterized file.
>I'm not totally clear about the semantic implications, BTW, and I'm not sure
>that the feature /itself/ is a good idea. I just think it doesn't look too bad.
If you find this idea interesting, you might also be interested in the idea
of adding just a little more power to compile-time defs to templating power
over included files with very little mechanism.
E.g., define max_tmpl.pxi:
TYPE def NAMES(x)(TYPE a, TYPE b):
return a > b if a else b
Then a client can simply
include "max_tmpl.pxi" TYPE="int", NAMES(x)=("int_" + x)
and just use the defined function int_max() as they like...
If something like NAMES() can refer to its outer definitions in its own,
you can do a nested hierarchy of namespaces:
include "max_tmpl.pxi" TYPE="int", NAMES(x)=NAMES("int_" + x)
>if you want to use bleading-edge Cython features in your code, you're pretty
>free to do so without caring too much about older Cython versions.
Eh. I don't think we're in any disagreement. To the extent trivial distutils
installs and packaging systems make life easy when you need the latest Cython,
great! To the extent Cython allows one to write Cython-version-agnostic or
Cython-feature-agnostic code, that's nice, too, but not a major issue. I only
called "nice", and I totally grant that this is not the strongest use case for
DEFINED (if there were include_once & WEAKDEF or a scoping-defining include).
Even the idempotent inclusion bit is only "nice compared to the messier state
checking version". Weak compile-time definitions/default parameters is likely
the most natural and direct use of something like DEFINED.
Better than using DEFINED to implement weak definitions would be a TYPE(name)
yielding something like one of {"bool", "int", "float", "str", ""}. The last
value, "", could mean "undefined" and obviate DEFINED(name). This would allow
more care in using compile-time values. E.g., rounding up if a client DEF's
a float where an int belongs or maybe doing something different based on the
type of the value. A glance at the compiler source suggests this is a bit
harder to do, involving ExprNode values at a later stage in Parsing.
Compile-time parameter issues become more interesting if you conceive of
things like 'pyximport' being more than a compilation convenience in an
edit-debug cycle, but rather a hook to tuning compile-time parameters
at run-time based on how they are about to be used by the end user.
Under an assumption that you are willing to wait for the C compiler to do
its thing, you may be able to give the C compiler more specific info and
thus get faster generated code.
cb
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
