Robert Bradshaw, 09.05.2012 00:12: > On Tue, May 8, 2012 at 6:47 AM, Vitja Makarov wrote: >> 2012/5/8 Stefan Behnel: >>> Vitja has rebased the type inference on the control flow, so I wonder if >>> this will enable us to properly infer this: >>> >>> def partial_validity(): >>> """ >>> >>> partial_validity() >>> ('Python object', 'double', 'str object') >>> """ >>> a = 1.0 >>> b = a + 2 # definitely double >>> a = 'test' >>> c = a + 'toast' # definitely str >>> return typeof(a), typeof(b), typeof(c) >>> >>> I think, what is mainly needed for this is that a NameNode with an >>> undeclared type should not report its own entry as dependency but that of >>> its own cf_assignments. Would this work? >>> >>> (Haven't got the time to try it out right now, so I'm dumping it here.) >>> >> >> Yeah, that might work. The other way to go is to split entries: >> >> def partial_validity(): >> """ >> >>> partial_validity() >> ('str object', 'double', 'str object') >> """ >> a_1 = 1.0 >> b = a_1 + 2 # definitely double >> a_2 = 'test' >> c = a_2 + 'toast' # definitely str >> return typeof(a_2), typeof(b), typeof(c) >> >> And this should work better because it allows to infer a_1 as a double >> and a_2 as a string. > > This already works, right?
It would work if it was implemented. *wink* > I agree it's nicer in general to split > things up, but not being able to optimize a loop variable because it > was used earlier or later in a different context is a disadvantage of > the current system. Absolutely. I was considering entry splitting more of a "soon, maybe not now" type of thing because it isn't entire clear to me what needs to be done. It may not even be all that hard to implement, but I think it's more than just a local change in the scope implementation because the current lookup_here() doesn't know what node is asking. Stefan _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel