Re: [Cython] Build module script
>>> On 21 April 2011 08:57, Vitja Makarov wrote: >> I mean simple script that run cython compiler and then build shared >> python module. >> It's much better then manually run cython then gcc or write makefile for >> this. > >Ah, I see. Yeah that might be convenient. Although there is always pyximport. I have a script I can contribute called pycc that might be a bit more than "simple". pycc [-c] [pyrexc|cython opts] [-- C-compiler opts] [Clink opts] as in pycc -c foo.pyx to produce foo.so in the simple case, or maybe, just as an example pycc -c -- -fmudflap foo.pyx -lmudflap if you had gcc as a compiler and wanted to turn on mudflap. The script itself is a Python script which uses an exec(file(os.environ["HOME"] + "/.pyccrc").read()) to configure things in the Python language itself for what C compiler and what default compile flags, C & Python include paths, libraries, etc. It only works on Unix right now. I'm not sure how hard it would be to adapt it to work on both Unix and Windows. It actually also works for "programs" rather than "modules" if you drop the -c as in pycc -- -I/usr/include/X11 whatever.pyx -lX11 to produce a --embed generated program called "whatever". In all, it makes for a pycc that behaves a bit more like traditional compiler front ends such as 'gcc' that take source all the way to a variety of outputs usable by the host OS. It works well in traditional Makefiles or just from the command line as one-off invocations as you're doing initial writing and testing or even "just seeing" if Cython works/helps in some isolated situation with some module or script. -- There's also some complexity that dates to pre-embed days, but which I personally find useful (or Pyrex users might find useful since I believe Pyrex does not have --embed). If you do not have the "-c" and you do have a ##MAIN## comment in the source file, it will indent all code after ##MAIN## into a "Main()" function called at startup. If there's no special comment it falls back to --embed. (we could spell this some other way if anyone wants more like the compiler option comment syntax "# cython: MAIN"). The upside of this feature is that with almost no mucking about with your Python script other than adding a comment, it makes variables local to Main() which allows optimizations in the main script logic that potentially make things much faster. I see 2X speed-ups in a few of my own speed critical programs. It probably would speed up CPython interpretation, too, but not nearly as much as the Cython operation in my various experiments. The downside of the feature is that does fiddle with global/local scope or mixed statements + defines + statments + defines. Those are all "very uncommon" patterns in my usage. Also, it does have a big ##MAIN## warning marker to let a reader know something special might be going on semantics-wise. And, hey, 2X speed for a 1-line diff. :) So, you can probably see why I keep that feature around, but I could also see if people didn't want an auto-functionizing-of-Main feature. Having it around also doesn't seem harmful if the spelling of the comment marker is nigh impossible to occur by accident. If you wanted me to delete that from the script before submission, I could, but it'd require a bit work and testing. Let me know if you want it. -- An entirely alternate proposal that might be better, but would also be more involved would be to make the "cython" program grow functionality to make it more like a traditional compiler front end. As things stand, "cython" (inheriting use-concept from Pyrex) works more like "cc -E" where output needs to fed to another stage to be compiled/linked. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Declaration syntax change
Greg Ewing wrote: >What would be the benefit of this? You're proposing to change >from something identical to C declaration syntax, which is >second nature for a great many people, to something that >looks deceptively like C syntax but isn't. > >I can't see that causing anything other than a massive >amount of confusion, anguish and hair-tearing. I would echo this, actually. While the C declarator syntax takes a while to get used to, there is actually a simple rationale for why it is the way it is: just one set of operator associativity and precedences. The way [], *, and function call ()s bind do not vary by context. One doesn't have to remember multiple sets of rules "tailored" for various contexts like declaration/typedef definition or casting vs operator application. I believe this is the "fact underlying" the reactions various folk here are having of "initially seemingly clearer, but oh wait..what about corner case?" There is a simplicity embedded in the seemingly backwards "operators you need to apply to get the base type" rule. The manual translation of C headers/decls to Cython is another good point. I think that it's a big departure from the perhaps hard to articulate "sweet spot" Cython/Pyrex are trying to hit straddling the C & Python worlds. Stefan Behnel wrote: >Also, C is only second nature to some people. A great many people actually >use Cython specifically to *avoid* having to write C. This is a fair point, but Pyrex/Cython have a decade plus long history here of being very close to C in this specific way, which is kind of a central thing..almost like a different way to spell the same type grammar. It's easy after a short while to visually see the translation. With whole new syntax and maybe parens in new, shiner places, I doubt seeing the mapping would be so easy for "hard cases". And easy cases are easy. On a separate relase-number-tying note, I also feel like the Cython 1.0 target (or even Pyrex 1.0) was always more about compatibility with "whatever Python you throw at the Cython compiler" than about finality to all the various extended Cython syntax areas. There are quite a few beyond-Py syntax areas at this point. So, *if* the conclusion is that there is a group will and solid rationale to let Cython allow a user to use an *alternate* type declaration sub-language/warnings/a wrapper/macro syntax, then I don't see any 1.0-release relevance. Cython grows just yet another way to specify the same things at whatever rev is easy. The 1.0 only matters if it's a strict backward incompatible proposal, but I sense a bit of discord on this response chain about that. Maybe changing "cdef" to be "cydef" would be a visual flag that an entirely different syntax is afoot? But then..sooo many ways to specify types. If you really want to be *that* different - arguably almost as much as different as simply requiring Python3 and annotations rather than having "cdef" at all, then why not go all the way and full on require Py3? Then a user confronts all the Py3 core syntax change and Cy2.0 (or maybe Cy1.5 as 3.0/2 or whatever) at the same time. And, why, the changes are even related to only-in-Py3 things to boot. Just my two cents, anyway. cb ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Declaration syntax change
Robert Bradshaw [rober...@gmail.com] wrote: >Yes, it still is. But it would be nice to get any such major changes >out of the way ahead of time. I think the "compiling Python" goal is so orthogonal to the goal of how "beyond Python syntax work" or simplicity of the parsing impl that "getting it out of the way" doesn't feel right. It's not like SciPy and a lot of other things don't have dependencies on lots of Cython code. >I don't think this proposal would require multiple sets of rules for >different contexts. Yeah. Probably. I just was explaining what I thought the mechanism behind people's reactions. They're used to something..wrinkles and all, potential for abuse and all, and honestly in terms of the bugs like that char *a,b malloc example -- visual bug finding and all. Not always, but a lot of the times there is just "confusion jello". Squeeze one place and it just oozes around. Also, Cython hasn't been so much about creating new Python syntax or new C syntax, and I think that makes it more approachable. Part of the question afoot, at least in the thread, was whether the learning curve for the new "less unclear code" is "worth the shift". Whatever common cases you make easy, nothing will ever hope to be as "search the internet"-supported as the C way. Part of debugging is a habit, a list in your head, and this proposes a new such list implicitly. So, just to confirm, I think what you propose would mean that the ubiquitous C string list is written sometimes as char *argv[] will have to change in every declared function signature that Cython sees? >That doesn't help with the goal of simplifying the language. Sure it doesn't. I said so, too. :) I'm not strongly advocating that. I don't mind how it is now. I prefer no change, but I understand this is not about pleasing me, specifically. So, I make arguments. ;-) >Python2 isn't dead yet. Also, I think changes are more easily done Your idea to simplify the language is a half measure. If simplicity of the compiler/syntax and Py similarity is what is *really* important then why not hatch a full measure Py3 plan as a longer-term goal? How long-term? Why, as long-term a goal as Py2 being mostly irrelevant, whenever that happens. I don't get the need for it to be a pre-1.0 goal. If there's a practical Py2 compatibility requirement, then why not a practical Cy <= 0.2 requirement, too? Just a leeetle more of the former than the latter and so on. All this just feels like a hair splitting judgement call. That kind of judgement just generally feels more appropriate for a post-1.0 mode of onward and upward language evolution to me not some last few releases move. Why not finish (mostly) all that you started to do with semantics and compiling and harden that as a release first? Then evolve something as basic as how to declare types. If Greg is as against the idea as his initial reaction, it'd also be a big divergence from Pyrex that is more basic than than just a cpdef or None-Arg or etc. kind of way since it impacts all type annotation. Type annotation (or inference) is the heart of .pyx over .py anyway. Not that there aren't a lot of other syntax variations, but in a lot of cases you can kind of code to the least common denominator if you care, like C++ compatible C. This would break that for any types beyond the most simple. Well, maybe least common Pyrex/Cy is more broken that I know anyway - I haven't tried to do it in a while. Cheers, cb ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
