On Mon, Jul 25, 2011 at 3:07 AM, mark florisson <markflorisso...@gmail.com> wrote: > On 25 July 2011 12:00, Stefan Behnel <stefan...@behnel.de> wrote: >> Vitja Makarov, 25.07.2011 10:25: >>> >>> 2011/7/25 Stefan Behnel<stefan...@behnel.de>: >>>> >>>> Vitja Makarov, 25.07.2011 08:41: >>>>> >>>>> 2011/7/23 Robert Bradshaw<rober...@math.washington.edu>: >>>>>> >>>>>> On Fri, Jul 22, 2011 at 3:12 AM, mark florisson >>>>>> <markflorisso...@gmail.com> wrote: >>>>>>> >>>>>>> For my work on the _memview branch (and also on fused types) I noticed >>>>>>> that UtilityCodes started weighing heavily on me in their current >>>>>>> form, so I wrote a little loader in the _memview branch: >>>>>>> >>>>>>> >>>>>>> >>>>>>> https://github.com/markflorisson88/cython/commit/e13debed2db78680ec0bd8c343433a2b73bd5e64#L2R110 >>>>>>> >>>>>>> The idea is simple: you put your utility codes in Cython/Utility in >>>>>>> .pyx, .c, .h files etc, and then load them. It works for both >>>>>>> prototypes and implementations, for UtilityCode and CythonUtilityCode: >>>>>> >>>>>> This sounds like it could be a nice way to organize our UtilityCode >>>>>> snippets. So far we haven't really needed any more templating than >>>>>> simple substitution, but for what you're doing I can see this being >>>>>> quite handy. This may also provide a more flexible way forward for >>>>>> supporting multiple backends. >>>>>> >>>>>>> myutility.c >>>>>>> >>>>>>> // UtilityProto: MyUtility >>>>>>> header code here >>>>>>> >>>>>>> // UtilityCode: MyUtility >>>>>>> implementation code here >>>>>>> >>>>>>> You can add as many other utilities as you like to the same file. You >>>>>>> can then load it using >>>>>>> >>>>>>> UtilityCode.load_utility_from_file("myutility.c", "MyUtility") >>>>>> >>>>>> I agree with you that having multiple related, named snippets in same >>>>>> file is worthwhile. What about >>>>>> >>>>>> ////////////////////// MyUtility.proto /////////////////////////// >>>>>> >>>>>> and >>>>>> >>>>>> ############ MyCyUtility ############## >>>>>> >>>>>> so the chunks are easy to see. >>>>>> >>>>> >>>>> C++ comments looks ugly. May be it's better to have something like this: >>>>> >>>>> /* UtilityCode: MyUtility.proto */ >>>>> and >>>>> >>>>> # UtilityCode: MyCyUtility >>>>> >>>>> That's also pretty easy to parse >>>> >>>> For the parser, it makes no difference. For a human, it does. A big fat >>>> marker like "/////////////////////" is hard to miss, whereas a tiny one >>>> like >>>> "/* ... */" is easily overlooked within a longer piece of code. >>>> >>> >>> Ok, but how many slashes should be there? >>> >>> I'd prefer something like: >>> >>> ########## UtilityCode: MyUtility ################ >>> >>> For both C and Cython >> >> I don't think the parser should care, and I don't think we should put much >> thought into this kind of detail, either. I'd suggest making the separator >> lines at most 78 characters long, and putting as many slashes or hashes in >> there as are needed to fill up the lines after writing the text content. >> What's important to the parser is that there's more than one hash/slash at >> start and end, and something parsable in between. The rest is up to those >> who write the file. > > Yeah, I simply mandated a minimum of 5 and a maximum of 30 on either > side (symmetry is not enforced).
I don't even think we need a max. > It's now 'MyUtility' and > 'MyUtility.proto'. If there's no objection to the ini-style header > (with requirements and other metadata possibly), then I'll implement > that one of these days. One drawback with the ini style is that it detaches the metadata from the code block itself (and require duplicating their names). - Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
