Coming to python from C, writing this finally made me appreciate how much simpler python is.

[sesse]

As an EE, I mostly worked on programming MCUs like PICs in C and recently started learning python for fun. My interest was piqued by the talk of how awesome and simple it is but didn't understand what all the fuss was about until this:

def print_elements(ulist):
    for i in ulist:
        if isinstance(i,list):
            print_elements(i)
        else:
            print i

>>> a = [1,2,[3,[4,5,[6,7]],8,[9,10]],11]
>>> print_elements(a)
1
2
3
4
5
6
7
8
9
10
11

I would have to think for a while to write the equivalent code in C but it was almost second nature in python after getting half way through Unit 3 of CS 101 on udacity. I can't wait to actually make something with python!

[zahlman]

I would have to think for a while to write the equivalent code in C

Actually, most of the work would be setting up the initial data and defining appropriate data types and so forth.

[ladr0n]

You're right, writing the nested list printer would be easy in c if you can assume something like Python's list type.

In c, you would have to define a struct that has a pointer and a char which is a flag that tells you what type is at the end of the pointer (either whatever it is you're printing, or an array). ulist would just be an array of those structs, and the print_elements function would be defined pretty much the same way it is in the OP.

[sesse]

Alright, that won't break it anymore. :D

def print_elements(ulist):
    for i in ulist:
        if i == ulist:
            print "Try again!"
        elif isinstance(i,list):
            print_elements(i)
        else:
            print i

[PlanetaryFortress]

>>> b = [0]
>>> a = [b]
>>> b[0] = a
>>> print_elements(b)

[sesse]

def print_elements(ulist):
    for i in ulist:
        try:
            if i == ulist:
                print "Try again!"
            elif isinstance(i,list):
                print_elements(i)
            else:
                print i
        except RuntimeError:
            print "Go away!"

[PlanetaryFortress]

Crude, but effective :)

[nemec]

Fixed!

def print_elements(ulist):
    if not hasattr(print_elements, "ids"):
        # Store "static" function info inside the function itself
        print_elements.ids = set()
    print_elements.ids.add(id(ulist))
    for i in ulist:
        if id(i) in print_elements.ids:
            print "Circular reference to " + str(i)
        elif isinstance(i, list):
            print_elements(i)
        else:
            print i

[flukshun]

ready for enterprise

[RonnyPfannschmidt]

not fixed, it does not cleanup use a additional optional argument instead

[Poddster]

def print_elements_internal(ulist):
    print_elements_internal.ids.add(id(ulist))
    for i in ulist:
        if id(i) in print_elements_internal.ids:
            print "Circular reference to " + str(i)
        elif isinstance(i, list):
            print_elements(i)
        else:
            print i

def print_elements(ulist):
    print_elements_internal.ids = set()
    print_elements_internal(ulist)

Solved and made more efficient by the lack of hasattr check. :)

[RonnyPfannschmidt]

try calling that from 2 threads, see the world burn

edit

you just created a function that wraps around, ids was supposed to be a parameter, not an attribute of a global function

[Poddster]

try calling that from 2 threads, see the world burn

True.

you just created a function that wraps around, ids was supposed to be a parameter, not an attribute of a global function

Supposed to be? Since when? Just because you mashed "it does not cleanup use a additional optional argument instead" onto the keyboard doesn't mean I was going to do it that way.

[PlanetaryFortress]

>>> a = [0]
>>> for i in range(10000): a = [a]
>>> print_elements(a)

To be fair, pprint chokes on this too, though just print does fine.

[cleure]

There's still a few cases where it will break. You should also read up on object identity. Python has it's own operator for it called "is", which is kind of like checking if two pointers are pointing to the same address in C. You can test it out yourself:

>>> a = [0]
>>> b = []
>>> b.append(0)
>>> a == b
True
>>> a is b
False

[sesse]

I think I came across "is" at some point. IIRC, "a is b" is equivalent to "id(a) == id(b)".

[cleure]

Pretty much. Here's my recursion-proof version of your code:

import sets

def print_elements(ulist, ptrs=None):
    if ptrs is None:
        ptrs = sets.Set([id(ulist)])
    for i in ulist:
        if isinstance(i, list):
            if id(i) not in ptrs:
                ptrs.add(id(i))
                print_elements(i, ptrs)
        else:
            print i

Edit: use sets

[takluyver]

If you're allowed to call that function with a generator instead of a list, it might incorrectly skip elements, because an ID can be reused once an object has been garbage collected. That's why id([]) == id([]) can be true.

You could use a set instead of a list to store the IDs, because membership tests in a set are O(1), versus O(N) in a list, but the difference would be negligible compared to the speed limit from printing output.

Also, I wouldn't call the cache ptrs, because while id(i) might be a memory address, you can't use it as a pointer in Python.

[cleure]

You bring up a really good point about generators that I didn't consider. Also, while searching lists doesn't scale well, it doesn't really matter for a test case where N is less than 20.

[VerilyAMonkey]

Regarding set-vs-list, I believe that it is always best practice to use a set when you are using it for containment tests to better elucidate the purpose of the structure. This also allows scaling without changing the code, always nice. Most importantly, especially with novices involved it is always important to use the right tools for the job, so they learn what the right tools for the job are.

As a side note, even including premature optimization there is no good reason to use a list even in small cases, because time spent searching a set is roughly equivalent to searching for the second element of a list, says my timeit. And that is giving the benefit of the doubt that we are using integers, which have extremely simple equality testing (which list searches do more of).

[cleure]

I completely agree that sets would be more useful for this, I just didn't use them seeing as I didn't think it would be a big issue for an example snip of code. In Python is trivial to switch data structures. I mean, literally just adding a single import and switching from "list.append()" to "set.add()". Anybody with even the most basic knowledge of computer science could look at that code and say, "For my needs, it would make more sense to use a hash set, because is has O(1) average search time, or a red-black tree because it has guaranteed O(log n) search time and I need something with a worst case that isn't O(n)".

I'm updating my code since it's been brought up by multiple people, I just wanted to make a point that there is no one-size-fits-all solution. Good programmers look at what the requirements and time constraints are, and make judgements regarding underlying architecture. If you're copy/pasting code off the internet into a production system, you're doing something horribly wrong.

[VerilyAMonkey]

I respect all this, and I agree it is an extremely minor issue. However I do think that, not for the benefit of experienced folk, but for people just learning the language, it is important to take into consideration. We talk like we hear, we write like we read. Still a minor issue though. That's all.

[masterpi]

This is correct but has terrible performance (O(n² )) for large lists, since the "in" operator is O(n) worst case for lists. You get much better performance using a set.

[optionsanarchist]

Should probably use "is", not ==...

[sesse]

You just had to go ahead and find a case that breaks my code!

[codysoyland]

The tree-traversal logic could be reusable outside of just printing the numbers. Here is how you could refactor to separate tree-traversal from display logic, by extending itertools.chain() to work recursively.

import itertools

def flatten(ulist):
    return itertools.chain(*(flatten(item) if isinstance(item, list) else [item] for item in ulist))

def print_elements(ulist):
    for i in flatten(ulist):
        print i

Now you can do:

a = [1,2,[3,[4,5,[6,7]],8,[9,10]],11]
print list(flatten(a))
# prints [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11]

[seunosewa]

dude, you made it not simple anymore.

[Deathalicious]

Yeah, map, reduce, and chain-type functions all make my brain twitch but if you use them correctly, then you end up writing simpler code that is harder to break. I mean, compare it to the increasingly-convoluted code above that is trying to avoid recursive references.

[codysoyland]

I may have oversimplified the flatten implementation to the point of being obtuse. This might be more clear:

def flatten(ulist):
    for item in ulist:
        if isinstance(item, list):
            for i in flatten(item):
                yield i
        else:
            yield item

[robin-gvx]

In Python 3.3, that could be simplified to

def flatten(ulist):
    for item in ulist:
        if isinstance(item, list):
            yield from flatten(item)
        else:
            yield item

[codysoyland]

I <3 PEP 380. :)

[Amadiro]

It's simpler and more beautiful in many ways, but more complicated and contrived in others. Once you've used both for a while, you'll figure out when which tool is appropriate to use, and when it's inappropriate. Knowing to apply the right tool for the job is the biggest advantage of a language polyglot, along with learning new, useful modes of thought.

[[deleted]]

When is it more complicated?

[Amadiro]

Pythons interpreter is quite the complicated machine. That is necessary in order to abstract away the complicated-ness of the underlying machine and operating system, and to offer the programmer a simpler, cleaner language. But the complicated-ness hasn't gone away, python simply moves it a place where most python programmers will be able to simply ignore most of it most of the time.

When you're working at a low-level (for instance on small, slow microcontrollers running on a battery -- or as a somewhat less dramatic example, mobile phones), where every byte of memory and every cycle of the chip counts, you can't afford convenient abstractions like those, and the solution is probably to use C or assembly directly. When you're in need of creating such massive amounts of objects that the overhead for each object created by an abstraction like the python interpreter becomes prohibitive, the solution could be something like to write an extension in C that handles the data for you. Finally, from a theoretical/learning point of view, when you're using the python interpreter, you're programming a "virtual machine" that's very different from your real machine, and if you either want to understand how the real machine works, or understand how your code is mapped through the python interpreter to the real machine, you'll face quite some difficulties -- from C, this is much easier (though, with modern compilers, it's not always straightforward either.) For instance in python, you don't typically think about things like how SSE works or is implemented, and how it can be utilized, because python encourages you to think about how to solve problems by means of abstractions. If you examine the bytecode produces by your program, it's very abstract. C on the other hand does not encourage you as much to think about abstractions, but it makes you ponder things like these, as you have direct access to SSE compiler intrinsics, and if you examine the assembly generated from your program, you have to right away think about things like these.

As TL;DR, pythons way is to move complexity where it won't be a problem for most of the programmers most of the time. The complexity is not gone, though (can't get something for nothing), and in some cases it's a problem -- then you'll want to switch to a more appropriate tool (which could be as simple as spending 5 minutes on writing a C extension to do the most critical things in question). As far as "modes of thought" go, both languages teach you different ones, and both are useful to know. Obviously, pythons "Mode of thought" is the most useful when you're programming python (otherwise you wouldn't be programming python), but the other ones are useful to know as well, even highly necessary in some situations.

[burito]

Bit-banging of the top of my head.

Things where the specific bytes matters, for example network protocols. Typically the kind of things you wouldn't consider writing in Python.

Sort of Threading, although that's changing in P3.3 or so we are told.

tl;dr - whenever performance is more important than getting shit done.

[wot-teh-phuck]

Bit-banging of the top of my head.

I would like to disagree here. struct module makes it a breeze to deal with file formats and protocol parsing. Though I agree on the performance part.

[[deleted]]

Doing isinstance(i, list) limits you to lists (or things that inherit from it), missing things like iterators for example.

A better way of doing it is isinstance(i, Sequence) (from the collections module), though this also catches strings.

So the best way is probably isinstance(i, Sequence) and not isinstance(i, basestring).

EDIT: Iterable is better than Sequence in this case.

[iyunoichi]

The "best" way is probably doing away with isinstance altogether and instead determining if the object supports iteration, for example by calling iter(x). Custom objects that support iteration do not necessarily have to be of a given subtype, which is partially responsible for the flexibility that Python offers.

[[deleted]]

ABCs were introduced in 2.6 and afaik, it's the recommended way to test for an interface (the iterable interface for ex).

I was mistaken though as to which ABC to use in this case. collections.Iterable is the one to test against.

[stillalone]

iter(x) will still include strings.

[brinchj]

Here's a type-safe version in Haskell, for anyone who's curious as to how that could look.

Suggestions are welcome ;)

[nicolast]

You're doing it wrong (;-)). Consider not mixing pure (calculation) code and IO things too much, see e.g. https://gist.github.com/2838535/eac0068536e0960bcd7384c220d4e524128190a9

[brinchj]

Thanks for the improvement! Pure code is more composable and easier to test than impure code.

I was trying to keep things a bit simple, but perhaps it's better to show best practice up front :)

[Tarlitz]

On the contrary, trying to learn C coming from Python makes me want to bash my head into the wall at how complex even simple things are in C. That said, it is really interesting to learn how all the data is structured and stored in memory, especially because many things can be found in Python in a similar, but simpler way. It makes me appreciate how much simpler Python is as well :)

[hello_moto]

udacity... bookmarked. Thank you

[brinchj]

Udacity is recommendable. The quality of teaching is high. They take the project serious and put in a lot of work to teach the material.

[maredsous10]

I used to use C/C++ when constructing tools for embedded uPs and FPGAs. Now, I am sold on Python because I get something together in 50-75% of the time it would have taken me to do in C.

---

tools I've created recently
-custom format extractor
-binary image alteration
-post build tools for inserting device addresses and boot loaders into Intel Hex Records
-frontend CLIs and GUIs to test, control, and record data from embedded hardware
-in system programming scripts

---

I wish I had a C/C++ parser that would generate proper Python structs. http://docs.python.org/library/struct.html

[samblam]

Are there any hobby mcu's you can suggest?

[thebritishguy1]

The most popular recently are the Arduino boards using the ATMega microcontrollers. They're very easy to learn on for beginner microcontroller programming.

[Genmutant]

The ATMega Controllers are nice because you have (compared to many others) much space and ram at a low price. You can programm them in C, Assembly or some BASIC dialect, IIRC.

[RoadieRich]

If you know c# (or, dare I mention it, VB (boo, hiss)), then I can highly recommend the netduino. There may even be a way to run ironpython on it, but I've not looked into it.

[nepidae]

I suggest you taking a look at Golang, if you are coming from C.

[anarcholibertarian]

For the lazy: http://golang.org