Why can't you assign to a list in a loop without enumerate?
In the following code snippet, I attempt to assign 10 to every index in the list a and fail because when I try to assign number to 10, number is a deep copy of the ith index (is this statement correct?). >>> a = [1,2,3,4,5] >>> for number in a: ... number = 10 ... >>> a [1, 2, 3, 4, 5] So, I have to resort to using enumerate to assign to the list: >>> for i, number in enumerate(a): ... a[i] = 10 ... >>> a [10, 10, 10, 10, 10] My question is, what was the motivation for returning a deep copy of the value at the ith index inside a for loop instead of the value itself? Also, is there any way to assign to a list in a for loop (with as little code as used above) without using enumerate? Thanks, Danny -- http://mail.python.org/mailman/listinfo/python-list
Re: Why can't you assign to a list in a loop without enumerate?
I see. Thanks for the helpful response. Danny Duncan Booth wrote: > "Danny Colligan" <[EMAIL PROTECTED]> wrote: > > > In the following code snippet, I attempt to assign 10 to every index in > > the list a and fail because when I try to assign number to 10, number > > is a deep copy of the ith index (is this statement correct?). > > No. There is no copying involved. > > Before the assignment, number is a reference to the object to which the ith > element of the list also refers. After the assignment you have rebound the > variable 'number' so it refers to the value 10. You won't affect the list > that way. > > > My question is, what was the motivation for returning a deep copy of > > the value at the ith index inside a for loop instead of the value > > itself? > > There is no copying going on. It returns the value itself, or at least a > reference to it. > > > Also, is there any way to assign to a list in a for loop (with > > as little code as used above) without using enumerate? > > a[:] = [10]*len(a) > > or more usually something like: > > a = [ fn(v) for v in a ] > > for some suitable expression involving the value. N.B. This last form > leaves the original list unchanged: if you really need to mutate it in > place assign to a[:] as in the first example, but if you are changing all > elements in the list then you usually want a new list. -- http://mail.python.org/mailman/listinfo/python-list
Re: Yield
Now that we're on the subject, what are the advantages of using generators over, say, list comprehensions or for loops? It seems to me that virtually all (I won't say everything) the examples I've seen can be done just as easily without using generators. For example, Fredrik's initial example in the post: >>> a = [1,2,3] >>> for i in a: print i ... 1 2 3 >>> sum(a) 6 >>> [str(i) for i in a] ['1', '2', '3'] >>> Carsten mentioned that generators are more memory-efficient to use when dealing with large numbers of objects. Is this the main advantage of using generators? Also, in what other novel ways are generators used that are clearly superior to alternatives? Thanks in advance, Danny On Nov 16, 3:14 am, John Machin <[EMAIL PROTECTED]> wrote: > On 16/11/2006 7:00 PM, Fredrik Lundh wrote: > > > John Machin wrote: > > >>> I would like to thanks Fredrik for his contribution to improve that. > > >> Call me crazy, but after an admittedly quick read, the version on the > >> wiki seems to be about word for word with on the docs.python.org version. > > > maybe he was thinking about the article I posted, or the FAQ link I > > posted in a followup: > > >http://effbot.org/pyfaq/what-is-a-generator.htm > > > which was based on my article and the glossary entry from the tutorial: > > >http://effbot.org/pytut/glossary.htm#generatorQuite possibly. > > > > >> Could you please tell us how you think the wiki version is an > >> improvement? > > > an "add comment" link? direct URL:s for all concepts in the language? > > extensive hyperlinking? semantic retargetable markup?Yes, they're great. > > Maybe I was thinking about the text contents only :-) > > Cheers, > John -- http://mail.python.org/mailman/listinfo/python-list
Re: Yield
> The more trivial the example, the harder it is to see the advantage. I absoultely agree. Thanks for pointing me out to some real-world code. However, the function you pointed me to is not a generator (there is no yield statement... it just returns the entire list of primes). A generator version would be: >>> def primes(n): ... if n<2: yield [] ... s=range(3,n+1,2) ... mroot = n ** 0.5 ... half=(n+1)/2-1 ... i=0 ... m=3 ... while m <= mroot: ... if s[i]: ... j=(m*m-3)/2 ... s[j]=0 ... while j>> x = primes(11) >>> x.next() 2 >>> x.next() 3 >>> x.next() 5 >>> x.next() 7 >>> x.next() 11 >>> x.next() Traceback (most recent call last): File "", line 1, in ? StopIteration >>> Danny Colligan On Nov 16, 10:49 am, "Richard Brodie" <[EMAIL PROTECTED]> wrote: > "Danny Colligan" <[EMAIL PROTECTED]> wrote in messagenews:[EMAIL PROTECTED] > > > Now that we're on the subject, what are the advantages of using > > generators over, say, list comprehensions or for loops? It seems to me > > that virtually all (I won't say everything) the examples I've seen can > > be done just as easily without using generators.The more trivial the > > example, the harder it is to see the advantage. > Suppose you wanted to sum the first 1 primes. A quick Google > fins you Wensheng Wang's > recipe:http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/366178 > Just add print sum(primes(1)), and you're done. -- http://mail.python.org/mailman/listinfo/python-list
Re: Common Python Idioms
> Is there a list somewhere listing those not-so-obvious-idioms? I don't know about lists of not-so-obvious idioms, but here's some gotchas (there may be some overlap with what you're asking about): http://zephyrfalcon.org/labs/python_pitfalls.html http://www.ferg.org/projects/python_gotchas.html http://www.onlamp.com/pub/a/python/2004/02/05/learn_python.html Danny -- http://mail.python.org/mailman/listinfo/python-list
