Tonight, I’m on page 126 of my Learning Python book. (It’s not exactly a page-turner.)
So far, no mention of mandatory source code indentation, except as the briefest aside. It’s a bit amusing how it’s the first thing everyone thinks of, yet my tutorial is playing coy. Well, be that way, you tease!
One thing it does mention is circular, or “cyclical” references. Object A refers to object B, which refers to object A.
>>> A = ['tiger']
In the above case, an entry in list A refers to list A itself. So if you tried to print A, you’d get an infinitely long list.
But Python detects this case, and substitutes
[...] instead. I’m going to assume this is list-specific, but that Python does this even just for standard types is heartening.
Does Python apply the same kind of logic when implementing automatic garbage collection? Will it recognize that a list, whose only remaining reference is from an unreferenced object within that list, can be gc’ed?
Per this page, the answer would appear to be yes: “Fortunately, Python’s cyclic-garbage collector will eventually figure out that the list is garbage and free it.”
The rest of that page, however, seems to imply that for more complicated custom classes, sometimes you need to take care of cyclical references yourself.
Is that a rare case? Or an inevitable gotcha as you start writing more complex Python programs?
My book is mum on the subject.
I bought Learning Python a couple days ago and have read maybe 100 pages in.
It’s no wonder people who like Objective-C like Python!
– Typeless variables, like Objective-C’s
– Garbage collection without Java.
– String addition using overloaded + without C++.
– Automatic upgrading of numeric variables, something you can’t do with C types like
– Mutable and immutable collection types like in Foundation.
What’s not to like?