On 02/06/13 15:14, Jim Mooney wrote:
On 1 June 2013 21:20, Steven D'Aprano wrote:
On 02/06/13 13:58, Jim Mooney wrote:
It's a little unclear to me where generators are more efficient.
When there are a lot of items, and you access the items one at a time, not
all at once. If there are only
The standard sorting in Python depends on a comparison operator. A
quick and easy comparison operator that Python uses for strings is
lexicographic ordering:
http://en.wikipedia.org/wiki/Lexicographical_order
The quick and dirty rule is: dictionary order, with each character
consistently tre
On 02/06/2013, Jim Mooney wrote:
> On 1 June 2013 21:20, Steven D'Aprano wrote:
>> On 02/06/13 13:58, Jim Mooney wrote:
>>>
>>> It's a little unclear to me where generators are more efficient.
>>
>>
>> When there are a lot of items, and you access the items one at a time,
>> not
>> all at once. I
> So how does one access a generator one element at a time? I thought
> next would do that so I tried:
>
> print(next(uneven_squares(10,1000)))
> print(next(uneven_squares(10,1000)))
> print(next(uneven_squares(10,1000)))
Each call to uneven_squares(10, 1000) creates a fresh iterator. You
may wa
On 1 June 2013 21:20, Steven D'Aprano wrote:
> On 02/06/13 13:58, Jim Mooney wrote:
>>
>> It's a little unclear to me where generators are more efficient.
>
>
> When there are a lot of items, and you access the items one at a time, not
> all at once. If there are only a few items, a list or tuple
On 02/06/13 13:58, Jim Mooney wrote:
It's a little unclear to me where generators are more efficient.
When there are a lot of items, and you access the items one at a time, not all
at once. If there are only a few items, a list or tuple has less overhead and
is easier to use.
Below I'm cre
>
>
> print(list(uneven_squares(10,1))[2:10]) #slows as y gets bigger, then
> dies
>
>
You'll want to stick with sequence operations that do not force the entire
generator's output. In this specific case, try itertools.islice.
http://docs.python.org/2/library/itertools.html#itertools.islice
__
It's a little unclear to me where generators are more efficient. Below
I'm creating a list of non-even squares. I figured Python would be
smart enough to see I only wanted a small slice of a large generated
list, but as I increased y, Py got slower and eventually died of a
memory error. If I don't
Dave Angel davea.name> writes:
>
> > str_num = '1234567890'
> > n = 5
> >
> > strings = [str_num[i:i+5] for i in range(0, len(str_num)) if
> > len(str_num[i:i+5])==5]
>
> If you changed the range() size, you could eliminate the extra if test.
> After all, the only ones that'll be short are t
On 01.06.2013 07:47, Sarma Tangirala wrote:
I had a quick question on how string compare works. If did '1001' <= '999'
I get true. I know how the string compare works but I was wondering why it
were so. Why doesn't the string length factor into the comparison?
Because usually you are interested
Sarma Tangirala wrote:
> I had a quick question on how string compare works. If did '1001' <= '999'
> I get true. I know how the string compare works but I was wondering why it
> were so. Why doesn't the string length factor into the comparison? For
> example, If I compared character-by-character
11 matches
Mail list logo
