Welcome back for this way of the programmer segment
on good design practice for creating Nested Data.
Basically, be consistent.
Don't mix two levels of nesting with three for example.
Consider this example, this is bad design practice, on line 1,
we've got a variable nested one which is assigned to a list,
it has a couple elements and that are
numbers and then it's got a few elements that are lists.
Having this mixture is going to make it hard to traverse the Nested Data structure.
So for example, if I try to run this now, I'm going to get an error.
The error tells us that we are trying
to iterate through an integer object on line number 4,
but to understand what's going on,
we need to go up a couple lines first.
So on line number 2, we are iterating through all of the items in nested one.
So X is going to be bound to one and the next time through X is going to be down to two,
and then the third time through X will be bound to the list ABC.
Each time, we're going to print out level
1 just to remind us that we've made it through one more iteration.
But then the action is supposed to happen at line 4.
We've seen something like this before if we really had
lists all the way through is all of the elements of nested one being list,
and we could iterate through each of those items where X was going to be a list like ABC.
We could iterate through it and print out each of
the items saying something like level 2:a.
Our problem is happening when we
get to this for the very first time we've printed level 1,
and then we're getting an error on line 4 because
X is bound not to a list but to the integer, 1.
So when we now say for Y in X,
we're saying for Y in this so that's the Integer object and it is not iterable,
it is not a list.
The problem is really coming because we wanted to get to items like a, and b,
and c which does require this nested iteration,
but our data wasn't structured in a clean way,
so we couldn't just always assume that X was going to be a list.
Sometimes X was going to be a number.
So let's see how to solve that problem.
The basic solution is to use some special case logic.
In our code, we'll check whether the type of X is a list.
If it is, we'll do a nested iteration and if it's not,
we'll do something else.
So that's what's going on, on line 4.
We started iterating X this first time is bound to the value,
1, and we check is the type of X list.
If it is, then we would iterate through it but since
it's not, we're just going to print it.
So I would expect one to show up and then we'll do our second iteration,
X will be bound to two,
and we'll get two to show up in the output window.
The third time, X is going to be bound to a list a,
b and c. Now when we check is the type of X list,
the answer will be true,
and so we'll iterate and for
each Y will be bound to a and then to b and then to c. For each of those,
we'll get something that says level
2:a and level 2:b and so on.
So lets just check my reasoning there and see if that's what actually happens,
and indeed that is what's happening.
Each time we get to line 3,
we print out this level 1,
and the first time,
X was bound to the value 1,
so we just print it.
The second time, we print two,
the third time we iterate through the list abc and we execute line 6, three times.
Once printing out a, once printing out b,
and once printing out c. And you can imagine this would get pretty
complicated with lots of special cases if we had more levels of data nesting,
and we were not consistent about the level of nesting.
The solution when we are in control of the data structure is to make it very
regular with always the same kinds of items in the same level of nesting.
In other words, don't mix integers, lists,
and dictionaries as items in a single list.
Sometimes however, we aren't in control of the data structure.
Maybe our evil predecessor on the project structured the data in a not very careful way.
Or we get it from an external source that structured it however they wanted to.
When that happens, you'll have to notice and add some special case logic,
like the "if statement" that I've got here on line 4.
So that's my advice for following the way of the programmer.
Don't put trip hazards in your way,
make the Nested Data structures you're going to traverse be as regular as possible.
But if somebody else puts the trip hazards in your way,
be prepared to jump over them with some "if-then statements" to handle
differently structured data in different ways. See you next time.