Samuele Pedroni wrote:
Christian Tismer wrote:
...
I would like to understand why the annotator thinks this must
become a list, and how I can convince it to take a different action.
I think, using the variable variant would be adequate in this case.
you changed what happens on range calls annotation-wise, but not the
behavior of what should occur when types are mixed, this is specified by
the union operation which for list/ranges basically goes through the
ListItem.merge, which still has the behavior that mixing different-step
ranges unifies to list:
if other.range_step != self.range_step:
self.range_step = None
in listdef.py . If I have understood your changes you want 0 in this
case unless one of the range_step is already None meaning list.
Notice that if you change this you probably need to change
rtype_builtin_range because this assumes that it can use partially the
information in its arguments instead of about the result to decide
what to produce.
Ah, thank you very much, that was the missing spot. No magic at all,
but more places to look into. I will add something to cope with this.
Although I don't believe it is worthwhile to do in this case,
I guess it would be much more difficult to specialize on step?
thanks again - ciao - chris
--
Christian Tismer :^) <mailto:[EMAIL PROTECTED]>
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
_______________________________________________
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
