Steven D'Aprano 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 deprecated in Python 2.6, which means it
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)
> [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 makes
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 w
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),
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
~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
> 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.
On Apr 17, 1:39 pm, _wolf 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 xrange until your
_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
> cla
_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 `xxran
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 poo
12 matches
Mail list logo
