On Nov 24, 2009, at 12:08 PM, Stefan Behnel wrote: > > Robert Bradshaw, 24.11.2009 19:32: >> On Nov 24, 2009, at 3:55 AM, Stefan Behnel wrote: >> >>> Robert Bradshaw, 23.11.2009 20:33: >>>> == New features == >>>> - Type inference with the infer_types directive >>> Now that you mention it - why is there a directive for this? Can't >>> this be enabled by default? >> >> I think this came up before > > Yes, I recall something like that, too. > > >> first, it's a relatively new feature, so >> it'd be nice to get it out there a tested some, but more importantly >> it's such a large, backwards incompatible change that it didn't make >> sense to do it with all the other stuff going on on 0.12. There's a >> lot of code out there (much written by me, for example, when type >> inference wasn't even on the horizon) that uses the fact that >> assignment to an untyped variable is conversion to an object. > > Right, that's certainly a feature that people have their code depend > on. > Breaking it will break tons and tons of code, so it *is* good not to > make > it the default. > > How would you want this conversion to work in the future? With an > explicit > cast?
Yep. One can always do cdef object a = x as well. Somehow, eventually, I'd like to make it the default, but I don't see a clear path from here to there. Having it explicit is nice as well because it makes me uneasy that the behavior of code could change as the type inference algorithm evolves. (This is one reason that I think the alignment Python and C types was important for division and "x or y") I could also see something like @cython.infer_types(algorithm=...) which would be useful both for experimentation and consistency. > How does the current implementation actually handle diverging > assignments? > As in > > if test: > items = [] > else: > items = () > > or: > > items = () > if test: > items = [] > > or: > > a = 5 > ... > a = "test" > ... In all of these cases, it would deduce object is the only type "wide" enough to contain both options. >> One thing that I want to do is compile all of Sage with type >> inference >> on and see how much breaks. (In general, we're pretty good a typing >> variables, so I don't think it'll make a huge difference.) > > That certainly applies to C variables, but Python variables are a > different > thing here. > > >> Have you tried compiling lxml with type inference enabled? > > Well, I thought I did, but at the time I wasn't aware that it wasn't > on by > default, and I didn't have the time to figure out why it still > worked after > pulling your changes. ;-) > > Doing so now gives me: > > Internal compiler error: SliceIndexNode.infer_type not implemented I guess that's one reason it's not enabled by default yet :-) > I guess there's always a 0.12.1 ... :-/ Yep. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
