Stefan Behnel wrote: > Dag Sverre Seljebotn wrote: >> Before the C++ syntax sticks > > I actually think it makes sense. In declarations, the parameter can appear
Well it certainly has the advantage that C++ and Java knows what it means right away. > only behind type names, so parsing them would be trivial - except for > cases where the type name appears in an expression: > > isinstance(x, MyType<int>) > type_ref = MyType<int> vs. type_ref = SomeValue < something > 5 In general, foo<bar>(baz) can mean two things, and you don't know until you know what kind of expression foo is. This makes it virtually guaranteed that if Python gets generic interfaces somehow [1] this will not be the syntax of choice, as Guido hates these kinds of things even if it is technically possible to seperate it, possible to require that you write a<(b>a) or similar. Also in Python (and in Cython with metaprogramming/macro support!), one could envisage doing def f(): if wierd: return FooTemplate else: return BarTemplate f()<bar>(baz) # operators or template instantiation? won't know 'till runtime [1] Well, I suppose 3rd party libraries can already add interfaces, including templated ones, using metaclasses > Not sure if > > type_ref = MyType[int] > > makes this any simpler - it may at least simplify the parser, although > there might be further ambiguities with buffers, array sizes and indexing. Well, there's already ambiguities here (and still a regression compared to before I mixed things up with buffers) making the current parser approach suboptimal. One day when I get time I think I'll just introduce BracketOperatorNode, and leave deciding what it does to later transforms. One thing I really dislike in current Cython code is that the parser has to know whether things are types or not in a given context. (Although I think Robert fixed at least some of this.) BTW one can look at a template as a collection of types, and template instantiation as fetching the right type in the collection. > I also considered keyword arguments to the type (like Py3's "metaclass"), > but didn't find an obvious way to keep that information in the type name > when referring to it later on. > > cdef class MyType(SomeParent, templates=[T,V]): > ... > > cdef MyType(T=int, V=list) my_instance > my_instance = MyType(1,2,3,4, T=int, V=list) > > ... does that look readable? Hmm. It's an alternative to consider although I must admit my guts prefer MyType<T, V> to this. > That's sick. Looks like a scanner problem, though, not a parser problem. > The parser would know that '>>' doesn't make any sense at all at that > position (ok, it's C++, but let's assume a sane kind of 'sense' here). Well it is the same kind of problem as above; basically you don't know whether a<b<c>> d; is doing arithmetic or instantiating a variable until you can fully resolve what kind of identifiers a, b, c and d are. Just makes everything more complicated, and it is harder to parse for humans as well. The difference with a[b](c) is that you at least know how to structure the parse tree and the operator precedence just by looking at it without knowing anything about a, b and c. -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
