Dag Sverre Seljebotn wrote: > Stefan Behnel wrote: >> Dag Sverre Seljebotn wrote: >>> [a couple of unnecessary words stripped] >>> Robert Bradshaw wrote: >>>> OK, how about we get the feature with the less controversial syntax, >>>> and then re-open the discussion if desired. >>> Assuming you mean "simd[int, (stridespecs)]" is less controversial here: >>> >>> My main issue with this solution is what precendence it creates for how >>> project issues are settled. I don't like having a project culture where >>> stamina in these long threads is what counts in the end -- I'd much >>> rather have a clear, open voting process. >>> >>> But hear this: If both Robert and Stefan agrees about a syntax, whatever >>> the conclusion is, I won't say another word. >> Note that I raised a problem that you didn't solve so far, either. We >> currently have a syntax for an array type (basically the C syntax) and a >> syntax for the proposed SIMD type (int[:,:]). What we do not have is a >> syntax for a memory view that does not have SIMD semantics, especially not >> one that works in pure Python mode also. I assume that would use >> >> cdef MemoryView[int,int] v >> >> in the original setup, which I would call inconsistent with all other >> syntax we have for this. >> >> >>> (That is, you need to get the stridespecs in, and I'll state now that >>> I'd really, really prefer a Python-grammar-compatible syntax, unlike the >>> alternative proposals until now. Getting SIMD in pure Python mode with >>> the same type syntax is one of the neatest point in the whole int[:,:] >>> syntax.) >> Ok, so what about changing the template syntax then. Here's an idea. As I >> said before, I'm a big fan of keyword arguments. > > <SNIP making this thread longer, and not even offering a comment to my > blunt post> > > I'm sorry, I'm pulling out of the whole thing. It just takes too much > time on the mailing list. If somebody else want to finish the CEPs and > implement it then I'd be thrilled though. > > I suppose my real question was "can you just trust me on developing > numerics and Cython further in this direction, I have these ideas I've > been developing as an active numerics user and Cython developer over the > past year". > > I suppose the answer I got was "no, we have to do it all by comittee, > and go through all the points in detail on the mailing list". > > As it is, it looks like even if we could agree on a syntax, I'd still > have to go to the mailing list for every little nick and cranny in the > semantics, checking if it could be acceptable for both numerical and > non-numerical use. I just don't have the time for that. > > I think the real way forward for CEPs like these might be putting them > on hold until we can meet in person -- if we need to design by comittee, > let's be a real comittee. Emails just take too long, with days going by > over simple misunderstandings. (Even if writing an email doesn't always > take long, it is really testing for my patience to spend weeks before > asking a question to seeing a resolution.) > > The good news is that I can use what Cython time I have for better > mentoring Kurt and fix more boring bugs. >
While this is up, I just wanted to say that I'm sorry I wasted everybody's time with all those wierd proposals last spring, before my GSoC. I bet that was testing for your patience; I am truly grateful for the patience you showed me back then. -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
