Translate this to python?

[Steven D'Aprano]

On Fri, 06 Jan 2006 17:28:22 +0100, Xavier Morel wrote:

> Heiko Wundram wrote:
>> Xavier Morel wrote:
>>> I think that xrange is also soon-to-be deprecated (xrange eats a little
>>> less memory and is slightly faster to _create_, but much slower to
>>> _iterate over_ than range)
>> 
>> It might be slower to iterate using xrange, but xrange certainly has its
>> place in Python... Try the following on your computer:
>> 
>> for x in range(10**10):
>>     print x
>> 
>> for x in xrange(10**10):
>>     print x
>> 
>> Tell me which one doesn't overflow your memory. ;-) And before you come
>> telling me that these constraints are articial, I've _written_ programs
>> that had to iterate over 2**24 (the set of 10.* IP addresses), and I most
>> certainly wouldn't have wanted the machines to contain 384+ MB of RAM just
>> to store the number objects that range creates.
>> 
>> --- Heiko.
> 
> While xrange does have it's place in Python, it has very few actual uses 
> (yours being one of the few), and is usually more harmful than beneficial.
> 
> While the deprecation of xrange is not that "soon", it is part of the 
> Python 3000 PEP (http://www.python.org/peps/pep-3000.html#id38) along 
> with the deprecation of most FP-facilities of Python (filter, map, reduce).

Er, I thought it was range that was being depreciated, and xrange being
renamed range?

Or if you prefer, xrange being depreciated, and range being turned into an
iterator just like xrange *wink*

(I'm aware that xrange isn't implemented as an iterator, or at least it
wasn't, it was a unique object type. But it is conceptually an iterator.)

 
> It should also be noted that reimplementing xrange when needed is
> trivial and can be done with a 5-lines generator for the minimal version
> (1 argument, 0-n range) and probably less than 10 lines for the full
> blown version equivalent to the current one (including start, end and
> step arguments)

I have a problem with this attitude. Yes, it is true that many of the
features of Python scheduled for eventual depreciation in Python 3.0 (map,
filter, str.find, xrange, etc.) can easily be re-written in just a couple
of lines.

But these functions are useful, and I don't see that it is a step forward
to remove useful functionality from the language and expect people to fill
their programs with boilerplate code recreating that lost functionality.
Guido introduced True, False because so many people were writing 

False = 0; True = not False

at the start of their code. Will Guido end up re-introducing str.find
to Python 4.0 because people define this in all their code (complete with
deliberately included bug)?

def find(s, target, start=None, end=None):
    try:
        return s.index(target, start, end)
    except:
        return -1

On the other hand, there are genuine improvements: apply(f, L) is *much*
better written as f(*L). I don't think anyone will miss apply.


-- 
Steven.