On Jul 8, 2009, at 2:26 AM, Danilo Freitas wrote: > 2009/7/8 Robert Bradshaw <[email protected]>: >> On Jun 29, 2009, at 6:29 AM, Dag Sverre Seljebotn wrote: >> >>> Robert Bradshaw wrote: >>>> On Jun 27, 2009, at 3:02 PM, Dag Sverre Seljebotn wrote: >>>> >>>>> It's just the idea of being able to wrap "C++ libraries if they >>>>> are >>>>> not >>>>> too strange" I have some issues with. >>>> >>>> I have issues with this approach too, so no worries about selling >>>> short on that front :). (Wrapping strange libraries may be non- >>>> trivial, but hopefully no more so than using them.) Also, the final >>>> milestone of the project is to be able to wrap all of STL, which >>>> although it doesn't cover everything, does quite a bit. >>> >>> Sure, was just pointing out that a given path might lead you to >>> need to >>> define __inc__ or __deref__ and so on in order to be able to >>> support all >>> of STL (in fact __deref__ is a much better example; as the return >>> type >>> of "*it" must be declared, and "it[0]" may not be legal). >>> >>> I'd rather prefer C++ syntax over __inc__ or __deref__ (i.e. if we >>> didn't manage to "get rid of" the C++ semantics in the first >>> place). I >>> haven't found an alternative to inline C++ code OR supporting only a >>> subset, so if you're still against inline C++ code I'm inclined to >>> give >>> a +1 to C++ syntax, also on the constructor. >>> >>> But I don't really worry, and will leave it at this. >> >> To summarize, we're using Python syntax for now, and if there is time >> at the end of GSoC to implement references (which are a dependancy of >> the C++ style way of doing things) we'll reconsider at that point >> (this will also give us a bit of time to see how things feel). > > If we have time until the end of the program (and I hope we will), we > can use it and see how it will work (if fine or not fine). > If better, we may use it. > For now, we continue using Python syntax. If we decide it will need to > change it, we do it. > > I think that even we don't have time for it in the project, it could > be taken after project time-life. I it happens, I would like to > continue this work here :).
You are most certainly encouraged to keep working here! After you're initial investment to get to know the compiler, you'll even have an easier time of it. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
