On Sat, Oct 18, 2008 at 3:07 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > Manuel Metz wrote: >> Please see the end of the mail for the important point !!! > > Thank you--I see you are way ahead of me on this. See comments below. >> >> Eric Firing wrote: >>> Manuel, >>> >>> Although it doesn't hurt, I don't think it is worthwhile changing range >>> to xrange. From the 2.5 docs: >> [...snip...] >>> Note "minimal" advantage. xrange was intended for special-case use, not >>> general use. >> >> Eric, >> >> yes, I absolutely agree with you that this is only a small (minimal) >> advantage, probably not worth to worry about. Nevertheless ... >> >>> And from Python 3.0, http://docs.python.org/dev/3.0/whatsnew/3.0.html >>> xrange() renamed to range(), so range() will no longer produce a list >>> but an iterable yielding integers when iterated over. >> >> Python 3.0 will use xrange() by default, but it is then named range(), >> so from that _I_ conclude that xrange() should be used by default. You >> can also see the difference by using 2to3: >> >> """ >> for i in range(10): print i >> for i in xrange(10): print i >> """ >> >> gets converted to: >> >> """ >> for i in range(10): print i >> for i in range(10): print i >> """ >> >> That is, because 2to3 is a clever program. But: >> >> """ >> a = range(10) >> b = xrange(10) >> for i in a: print i >> for i in b: print i >> """ >> >> gets converted to >> >> """ >> a = list(range(10)) >> b = range(10) >> for i in a: print(i) >> for i in b: print(i) >> """ >> >> ;-) >> >> As you said, it's only a minimal advantage and 2to3 is a clever code!!! >> > > I am glad you brought the above to my attention--it completely changes > my point of view. It does appear that changing to xrange now, whenever > it will work (that is, when one does not *need* a list) will make the > transition to Python 3 more efficient and has no disadvantage with > present code. > >> >> (THE IMPORTANT POINT) >> >> But this brings me to another, more important point: In the axes hist() >> method, a keyword named "range" is used that is passed to the numpy >> histogram() function, which has the kwarg 'range'. Now, this is not a >> problem as long as the range() builtin function is not used in the >> hist() method. But there are a few loops in this method that use >> xrange(), so this code will be translated to range() in py3 -- and that >> will be a problem. A basic example with a pseudo-code: >>
The histogram function contains the code for the old behaviour and the new behaviour side by side. Now only the old behaviour uses xrange, while the new behaviour uses numpy's arange. The old behaviour will be gone altogether in release 1.4. >> """ >> def foo(x, range=(1,10)): >> print range >> for i in xrange(x): print i >> foo(10) >> """ >> >> with 2to3 --> >> >> """ >> def foo(x, range=(1,10)): >> print(range) >> for i in range(x): print(i) >> foo(10) >> """ >> which then fails. >> >> One solution would be to use a different keyword argument, maybe >> "binrange" instead of "range" and to throw a deprecated warning for the >> old keyword ??? >> > > Yes, I think the use of any builtin as a kwarg is a bug that should be > squashed via a new kwarg with a deprecation. Similarly, use of any > builtin as in internal variable should be considered a latent bug and fixed. > > Unfortunately, in this case, the badly-named kwarg is in numpy.histogram > as well. The best thing would be to try to get the same change made in > numpy so that mpl hist and numpy.histogram kwargs would stay in sync. > > To make matters worse, histogram has evolved in such a way that its > kwargs are a confusing mess. It is too bad that when the "new" syntax > was developed, the "range" kwarg was not changed at the same time. Indeed. > I don't know whether any more changes would be accepted now. I would oppose any change to histogram calling convention that does not fix a critical bug. I agree that using a built-in name as an argument is a bug, but I believe it is the lesser evil compared to asking users to change their code again. I've added a note in numpy ticket 797 suggesting that a py3k compatible numpy version should have the old behaviour removed to avoid the name clash. Thanks for bringing this up, Regards, David > If there is to be a new kwarg, I think I would call it "cliprange", > since it is essentially used to clip the input--unless "new" is not > True. It is not really a "bin range", because it can be set > independently of the bins. (I have not traced the code; I am basing my > statement on the docstring, so I could be wrong about what the code > actually does.) > > Eric > >> Manuel >> >>> This implies to me that range is the preferred form, and xrange is >>> intended to go away. >>> >>> Eric >>> >> [...snip...] >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
