Paul McGuire:
xrange is not really intended for in testing,
Let's add the semantic of a good and fast in to xrange (and to the
range of Python3). It hurts no one, allows for a natural idiom
(especially when you have a stride you don't want to re-invent the
logic of skipping absent numbers), and
On Fri, 17 Apr 2009 23:40:32 -0700 (PDT)
bearophileh...@lycos.com wrote:
Paul McGuire:
xrange is not really intended for in testing,
Let's add the semantic of a good and fast in to xrange (and to the
range of Python3). It hurts no one, allows for a natural idiom
(especially when you have
[soapbox]
Speaking about idiomacy, ...
[end soapbox]
soapbox]
I ALREADY STEPPED DOWN FROM SOAPBOX (on this topic)
[end soapbox]
thanks for the comment anyhow.
that an efficient `x in y` implementation used to be there and is gone
now is gross. guess i'll just have to live with my own
On Sat, 18 Apr 2009 13:05:34 +0200, mmanns wrote:
On Fri, 17 Apr 2009 23:40:32 -0700 (PDT) bearophileh...@lycos.com wrote:
Paul McGuire:
xrange is not really intended for in testing,
Let's add the semantic of a good and fast in to xrange (and to the
range of Python3). It hurts no one,
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
[...]
Speaking about idiomacy, it is grammatically incorrect to start sentences
in English with lower-case letters [...]
[...]
x.0 floats working with xrange is an accident, not a deliberate design
decision, and has been
lately i realized a slow running portion of my application, and a
quick profiling nourished the suspicion that, of all things, calls to
`xrange().__contains__` (`x in b` where `b = xrange(L,H)`) is the
culprit. to avoid any other influences, i wrote this test script with
class `xxrange` being a
_wolf wrote:
lately i realized a slow running portion of my application, and a
quick profiling nourished the suspicion that, of all things, calls to
`xrange().__contains__` (`x in b` where `b = xrange(L,H)`) is the
culprit. to avoid any other influences, i wrote this test script with
class
_wolf wrote:
lately i realized a slow running portion of my application, and a
quick profiling nourished the suspicion that, of all things, calls to
`xrange().__contains__` (`x in b` where `b = xrange(L,H)`) is the
culprit. to avoid any other influences, i wrote this test script with
class
On Apr 17, 1:39 pm, _wolf wolfgang.l...@gmail.com wrote:
can it be that a simple diy-class outperforms a python built-in by a
factor of 180? is there something i have done the wrong way?
omissions, oversights? do other people get similar figures?
cheers
I wouldn't say you are outperforming
One might wonder why you are even writing code to test for existence
in a range list, when blee = blah bloo is obviously going to
outperform this kind of code.
-- Paul
the reason is simply the idiomacy and convenience. i use (x)xranges to
implement unicode blocks and similar things. it is
~flow wrote:
One might wonder why you are even writing code to test for existence
in a range list, when blee = blah bloo is obviously going to
outperform this kind of code.
-- Paul
the reason is simply the idiomacy and convenience. i use (x)xranges to
implement unicode blocks and similar
On Fri, 17 Apr 2009 13:58:54 -0700, ~flow wrote:
One might wonder why you are even writing code to test for existence
in a range list, when blee = blah bloo is obviously going to
outperform this kind of code.
-- Paul
the reason is simply the idiomacy and convenience. i use (x)xranges to
12 matches
Mail list logo
