> I can't seem to find the thread now, so this is from memory. There's the > points already mentioned (quoted below); I consider it extremely valuable > myself that templates written in Cython are potentially exportable to > Python using the same syntax. > > Also it can be parsed more cleanly. E.g. > > a<b>(c) > > Is that two comparisons or calling the constructor of a template? No way > to know until you check the type of a and c, meaning the syntax is > ambiguous until you check that. (In Python this kind of thing is a > showstopper for a new syntax; Guido argues that a simple parser means a > language that's also simple to parse by humans).
Yes, this makes sense. > (Even C++ struggles with this kind of thing; requiring you to write > "a<b<c> >", i.e. the extra, ugly space to avoid writing a right-shift > operator.) I agree that the C++ syntax is not necessarily the prettiest as well. > In Cython we're not so picky about things like this and there are ways of > resolving ambiguous syntax later in the stage; but it does mean that if > Python gets generic types (which isn't entirely impossible), <> is out of > the question, while we could hope for Python using [] (Guido already used > it in mock demonstration syntax for the purpose). Ahh, then this makes total sense. Cheers, Brian >> On Thu, May 21, 2009 at 11:16 AM, Dag Sverre >> Seljebotn<[email protected]> wrote: >>> A decision is needed here within a few weeks; it would be great if any >>> core developers who don't care could respond to vote 0. >>> >>> The decision was made to use [] for templates. To reiterate the main >>> arguments: >>> >>> - It leaves the way open for exporting pre-instantiated templates to >>> Python in a /very/ natural fashion. >>> >>> - Templates are a bit like a collection of types anyway. >>> >>> >>> However this creates some syntax issues: >>> >>> A) Currently >>> >>> cdef object[int] arr = ... >>> >>> can be used for PEP 3118 access on a generic object. While not a >>> technical problem (object will never become a template), it looks a bit >>> odd when introducing with a template feature. >>> >>> B) How would a templated buffer type look like? MyType[int][float]? >>> >>> Proposal: >>> >>> The object[int] syntax is removed (are anyone using it?). This is >>> basically done by making any cdef class with the >>> __cythonbufferdefaults__ magic attribute become a "buffer template". >>> Such cdef classes cannot be templates. Any other class cannot be used as >>> a buffer-supporting object. >>> >>> This removes functionality (much numeric code could care less about >>> whether the underlying object is an ndarray). As a substitute, the main >>> idea in http://wiki.cython.org/enhancements/buffersyntax is accepted, >>> which is to use >>> >>> cdef int[:] arr = ... >>> >>> for generic access, without any object access (this means that for now >>> only indexing and getting the shape is allowed at all.) >>> >>> I've been wondering a lot about whether this is the right way, and it >>> still seems so, even if it means that there will be (and likely continue >>> to be) two different ways of accessing a buffer; one through an explicit >>> "buffer type" and one through an "automatic template". >>> >>> -- >>> Dag Sverre >>> _______________________________________________ >>> Cython-dev mailing list >>> [email protected] >>> http://codespeak.net/mailman/listinfo/cython-dev >>> >> _______________________________________________ >> Cython-dev mailing list >> [email protected] >> http://codespeak.net/mailman/listinfo/cython-dev >> > > > _______________________________________________ > Cython-dev mailing list > [email protected] > http://codespeak.net/mailman/listinfo/cython-dev > _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
