Book Review #11

Python Pocket Reference
Mark Lulz
11/21/13

I have Learning Python book and Programming Python book. They're good books. However, as tutorials go, they are too much. I don't blame Mark Lulz, the author, but those 3000 pages are too much for use as reference. There is another book: Python Pocket Reference. Unfortunately, I do not find much use for it. First of all, you need to have read Learning Python book in order to understand the terminology. Also, Python is surprisingly a thin language for something so complex. So, the pocket reference book did little to help me.

Bottom line? Get the excellent Learning Python book, and write your own Pocket reference book!

Book Review #10

Programming Python
Mark Lulz

Programming Python is the more practical of the Learning Python-Programming Python pair. In all, I like this book better. I'm more of a practical programmer than theoretical one. As a Perl fan, I hate to see the oft-repeated attitude that Python is a "better Perl". Other than that, I have no problem. I am somewhat disappointed to discover that the thick 1500 pages tome does not cover PyGame. It does get a mention, but come on. Don't you think that if you don't have a space to cover that, at least reference some good books on it? I'm rather disappointed. Granted, the main purpose of the book is to write a clean, portable python programs, and in that mission, it succeeds admirably. But the lack of other resources cited remains a rather curious omission that would have made the book even more complete.

I also think that as good as it is, the book fails to convey Python's strength. Take this example from the clock (Ch 11, p748):

1. def point (tick, range, radius):
2.     angle = tick * (360.0 / range)
3.     radiansPerDegree = math.pi / 180
4.     pointX = int( round( radius * math.sin(angle * radiansPerDegree) ))
5.     pointY = int( round( radius * math.cos(angle * radiansPerDegree) ))
6.     return (pointX, pointY)

Reading the code makes it obvious that this is just a way to return a point, given angle and distance. In other words, polar coordinates. There are several marks, that I want to address.

1. Why the parenthesis in (360.0 / range)? Precision should be no problem. The only reason that I can think of is variable types. I mark this as a drawback of strongly typed languages. The parenthesis should be optional.
2. radiansPerDegree? Some languages provides that as a function. Why do you have to built your own?
3. int( round( ? Come on. In any other language, it's either int() or round(). Definitely not both!
4. math.sin(), math.cos(). Do you seriously prefer this to sin(), cos()?

And that's just the language. I suppose, if I'm feeling mischievious, I can point out that radiansPerDegree is completely internalized, and thus unnecessary complication. Just because the function takes radians, does not mean you have to convert degrees to radians. Like so:

1. angle = math.pi * 2 * tick / range

You may put any necessary parenthesis where you want. If simple is better than complex, then the text code doesn't show. What's the matter? Can't think in radians? Don't you think that as a professional programmer, you should learn it? No computer language is so good that you can be sloppy!

And if I really nitpick, I guess I can complain about associating X with sin, and Y with cos, instead of the "proper" way X with cos, Y with sin. But I won't. ;)

And here's another thing, later in the book (p. 761):

1. class PPClockBig(PhotoClockConfig):
2.     picture, bg, fg = gifdir + 'ora-pp.gif', 'navy', 'green'
3. 
   
4. class LP4EClock(GilliganClock):
5.     size = 700
6.     picture = gifdir + 'ora-lp4e.gif'
7.     bg = 'navy'

and so on...

I counted 9 such classes. People have pointed out to me that Python is so powerful that it can take such flexible class arrangements. I agree that the language is powerful in order to take that. However, I'd rather see it in tabular form. A straight array will be simpler, cleaner, and clearer. Plus the advantage of loading it from file, so that you don't have to change the code just because you want a new background color. BTW, Perl can trivially do it via HereString, while retaining simplicity and clarity.

The book ends with a bad joke:

"But how will I know why Python is better than Perl?"

"You will know. When your code you try to read six months from now."

I think that joke is in poor taste. You're trying too hard to position "Python as the better Perl". My response?

"I get it. Your brain is spaghetti. However, instead of straightening your brain and learn how to code properly, you simply blame your tool. What kind of a workman, are you?"

I can still recommend the book, but it's not as good as Learning Python. Little distractionary things pepper the book, and I do not enjoy it as much.

Book Review #9

Learning Python
Mark Lulz

I'm trying to learn Python as part of my Raspberry Pi experience. O'Reilly has been a great source of learning in the past, and I do not see any reason to stop. I bought, sight unseen, three books: Learning Python, Programming Python, and Python Pocket Reference. All by Mark Lulz.

The content of Learning Python is comprehensive, informative, and extremely thorough. Worthy of any O'Reilly book. Unfortunately, I find the later section to be boring, and I was nodding my head off. The author, to his credit, understand this and wrote that the latter section is part of the advance section that only the most dedicated users will want to touch. He also helpfully highlights parts of the language that, at first sight, looks niche, but actually are used rather often. So, that is very helpful when you want to prioritize in learning the language.

The book is a tutorial book. The author provides plenty of explanations of how things work. Sometimes, I feel like there's too much information, but unlike fluffy padded books, I can't remove materials without sacrificing information. Therefore, I can say that the book is worth the number of pages it contained. There's only one complain. The book is 1500 pages long!

Don't you think that, maybe, it's better to split this tome into 3 books, instead? ^_^;

Another gripe, is that I think that the author is trying hard to position Python as "the better Perl". In that, it has all the Perl advantages, without the disadvantages. I'm afraid that's a common opinion, although I do not share it. One of the complain was that it's easier to write Perl from scratch than to read it. I take it as Perl is so easy to write, rather than Perl is hard to read. Another thing is that, taken in full context, Python is full of special cases that differs by little, each to its particular purpose. I keep thinking, "you mean you prefer this to Perl?"

Of course, it should be obvious by now, that I do not think much of Python. In fact, all of Perl's criticism can be easily levied to Python just as well. I never did find reading Python script easier than any other language. It's the programmer, not the language. In fact, at the end of the book, where the advanced section lies, the author warned the readers to use the knowledge judiciously, knowing that if the features are misused, it can lead away from Python's philosophy. You know what? Apply the same advice to Perl, and you'll get the same result!

So, now that I learned Python, I'm afraid to say that I am not a convert. However, as far as learning Python goes, this is the gold standard. I have yet to see any treatment that is more sophisticated, comprehensive, accessible than this tome. Just, please, split it into 3 books. My hands got cramped just holding it up. ;)
Highly recommended.

Raspberry Pi Journal #33

Learning Python

The Raspberry Pi device was conceived as educational enabler device. Part of the target audience was kids. That's why it has Scratch programming on it. Also, the official programming language is Python. In fact, that's the "Pi" in Raspberry Pi.

So, after I built the LCD Display kit, it's time for me to learn Python programming. My chosen language was actually Perl, since it's so easy to write in it. But since the official language is Python, I guess I should learn it.

The book I chose is O'Reilly Learning Python. O'Reilly books are consistently high quality. Very few is sub par. So, if I am to buy a learning book sight unseen, it's O'Reilly.

You can see the the picture is that of a rat. Where's the snake? Sorry. That's another book: Programming Python. About the same size and price of this book. The price? $70 with tax. The size? 1500 pages.

Ahem. 1500 pages. Are you nuts? Is that one book? Don't you think, like maybe, it's better to split it into 3 books? After all, isn't that what Prof. Donald Knuth did with his book? Oh, and the other book is the same size?

That makes it 3000 pages total. And remember, Raspberry Pi is designed to teach kids how to program. Somehow, no matter how hard I try, I just can't imagine kids would be wanting to pick this book up, much less two of them.

I must be getting old. It used to be that I can devour such book in a couple of days. So far, because of other commitments, I managed to read 300 pages into it. And learned different object types.

300 pages to explain the different object types.

470 pages will give you loops.

I admit that the book provides an excellent foundation of how Python works. But 300 pages? It deals with the powerful flexibility that Python have that lets you handle complexities with ease. Except, I don't want to go there. I have yet to see source code that maximized the full potential of the language.

I still remember that Learning Perl and Programming Perl book combined is less that this book. I guess it just goes to show you that today's computer, and programming language, is very powerful indeed.

But still, are you sure you want to foist this ultra powerful programming language to kids, even if they have Scratch programming background?

Raspberry Pi Journal #32

Adafruit LCD w/ Keypad First Test

I finally installed the script to run Adafruit LCD w/ Keypad Kit. Mine is the RGB version, so I get all the colors. It was rather scary trying to enter the unknown. I did it with some trepidation. Obviously, I backed up my system!

Turns out there's no trouble at all.

I'm not running Occidentalis, so I have to do things the hard way, which isn't hard at all. I opened up the file /etc/modules and there's only one entry on it. I simply added these two lines at the end (per instruction)

i2c-bcm2708
i2c-dev

And that's it. Reboot for it to take effect, and install some programs. Again, this is all mentioned in the helpful instructions.

• sudo apt-get install python-smbus
• sudo apt-get install i2c-tools

By the way, I make sure that I don't already have the package. But it's not necessary. The installation will install the latest package version if necessary, but that's about it. Also, i2c-tools install a set of program into /usr/sbin.

Next, I went and installed the source code from github. It turns out that I already have git on my computer. So, all I have to do is clone it from the directory.

• git clone https://github.com/adafruit/Adafruit-Raspberry-Pi-Python-Code.git

And that's it. Very quickly done. Next, install update Python to allow GPIO programming:

• sudo apt-get install python-dev
• sudo apt-get install python-rpi.gpio

Thankfully the python demo script auto-detect my device. At first, I wasn't sure that the program is running. Then I remembered that the LCD is contrast sensitive. I pulled out my trusty Swiss Army Knife. Popped out philips screwdriver, and adjusted the contrast. I was elated when I see the lettering, and downright happy when the text and the color changes per button presses!

Oh, yeah! I guess I'm a hardware engineer, now! Well, I guess I should learn Python programming so I can do cool stuff with it!

Book Review #2

Programming the Raspberry Pi

Getting Started with Python
Simon Monk

The problem with Getting Started series is the extremely limited amount of information that the author can pack into such a short space. However, I think Simon Monk does an admirable job doing it. The book is divided into two parts. The first part deals with Python as a language and all the idiosyncracies the language has. The second part deals with communicating with various modules available on the market.

I really wish that Simon Monk would write two books: One deals with Python language, and the other deals with hardware projects. As it is, there is quite a bit cut out of the book. There's a lot of dependence upon internet resources. It's not that the information presented is lacking. It's just that it's such a bare bones that you have to read the book extremely carefully, as to not miss anything, or worse, misunderstanding the information presented.

There is an obligatory chapter dealing with installing the program, or in this case, setting up the Raspberry Pi. I wonder if you need that much details, but it's actually a compact form to setting up and installing Raspberry Pi, while still providing more details than what the Foundation provide. This isn't good or bad. It's just a design decision that we should be aware of.

The "do-what-I-do" teaching technique is not what I think a good way to teach. Sure, it will cause the students to get results very quickly, but can they expand the knowledge? Most of the time, they won't. I think it's a pity that the book is so short, because the information is presented rather well. It's just that the real foundation is not explained. Woe befall readers who did not do his homework! 

I'm used to read condensed text, and this text is not the most condensed. However, there is a judgement call here. Do you want to condense the text so much that it takes effort to read, even though there's more material? Or do you want to sacrifice detailed info in an effort to make it readable? I think the author did a great job balancing information and readability. If only more authors write like this, I will be happy!

I was pleasantly surprised to see Hangman game in there. In truth, the game is so easy, it is easily implemented in just about any language in one hour. For some reason, most book authors didn't do that. They simply choose a simplistic (and useless) program to make a point. So, I'm glad to see a good game in here.

I'm not so happy that the function list is rather short. I'd like to see a few pages of it, outlining the most common usage. It's a judgement call, but I'd say I can use a few more convenient functions and their relevant modules in one place.

I'm not too happy about drawing section, either. Perhaps it's just me, but the author never answered the question, "How do you put a dot on screen?" 

As far as I'm concerned, if I can put a dot on screen, I can do anything, albeit slowly. I don't have that information. I do have lines, ellipse, and rectangles. I guess, I can make a 1 pixel rectangle, but then it'll be even slower. I know SDL does allow surface, but I don't see it there. There is a discussion about writing an arcade game, but I think the game falls into the simplistic side, and not the sophisticated side. 

The rest of the short pages deals with hardware. There is a good project selection here, including roving robots. There is enough subject to please most people. This is where I think the format is at fault. I'd like to see more pages on this subject! Thus, I think it would be helpful if the author would write 2 books, instead of one.

All in all, it's a good effort by Simon Monk, marred only by the small number of pages inherent in "Getting Started" series. I can recommend this book to any Raspberry Pi user interested in getting started in Python.

Raspberry Pi Journal #8

Too Many Failures

In order to learn something new, you must first admit that you are stupid. After all, if you are smart, then you already know whatever it is you're learning.

Raspberry Pi has gone so far, and it's a relatively stable system, now. Furthermore, with NOOBS, installing the operating system is as easy as selecting item from a menu. Unfortunately, that's not all there is.

I know the Foundation has decided on Scratch for beginners, and Python for everybody else. I will not question their decision. However, I am used to having BASIC programming language to teach beginners.

My view is strengthened by the fact that Nintendo DSi/3DS has an app called Petit Computer. I happen to think that it is the perfect system to learn computer programming: Portable, cheap, convenient, and relatively powerful. There are numerous games exists to stand as template for what to do. That is all you need to learn computer game programming, and the one I recommend to everybody.

Enter Python. Even assuming that people have no problem learning the keywords, there exists certain conventions that will trip up people. The fact that Python tutorials use lists concept quite a lot, and no compatibility in BASIC, will certainly trip up a lot of people. It certainly tripped me, and I'm used to doing Perl and Lisp. I have experience in dealing with recursive lists, but is that something you want to teach to beginners? I don't think so.

Then there is a reliance upon libraries. Some of these, are in fact, rather shallow. By that I mean if you just spend a little bit more time explaining the algorithm behind the scene, you could've taught people on how to roll your own. Alas, that knowledge is kept secret. I, for one, know that depending upon libraries will hurt you long term. I depended upon Linux OS to process my procedures. What happened when I moved to Windows? Yup, big fail.

The problem is, I have no satisfactory BASIC language for Raspberry Pi. BBC Basic is too old. SDL Basic seems buggy and underpowered. Doesn't seem to have array. BASIC256? I forgot what it was, but I'll do a wait and see. Will visit it later, maybe sometime next year.

Somebody in the forum suggested that Python is the new BASIC. I'm still investigating it, but so far, there's nothing to suggest that Python can be friendly to beginners. That is, if you do it right, and not insists upon using efficient, high-level construct in Python.

Perl has a friendly attitude: There's more than one way to do it. Since different people do it different, Perl has the reputation of being "write only". I admit that learning to program differently is not a skill other people can master easily. But you can learn to do great things with Perl easy, just as so long you don't have to deal with other people's program!

Python, on the other hand, has the attitude of: There can only be one way to do it: the right way! In theory, it sounds great. In practice, there is always somebody who did it the boneheaded way, anyway. While my Python skill has improved tremendously, there is the odd occasion when I'm stumped in reading somebody's Python program. Pseudocode-like? I don't think so.

Personally, I prefer Processing, which is a bad name due to the difficulty of searching it using search engine. "Processing" is a very common word! I like the language, though. There are two problems associated with Raspberry Pi. (1) It's not officially supported. (2) It runs very slow when it does run.

I can't vouch for non-supported slow poke as good introduction for beginner!

So that left us with Python. I don't like it, but assuming I stay away from more advance techniques, I guess it's workable. I will continue to study the language and we'll see what happens.

Another failure is my attempt to back up my SD card. Yes, it's still not backed up. Would you believe that I run into "Out-of-Space" error? Both cards are formatted blanks. How come I don't have enough space? My guess is that I need to either partition the card slightly less than 14 GB. Maybe 10 GB. That way, it gives a leeway for other stuff.

Then again, my flashdrive has "File too big" error when it reaches 4GB. Another guess is that FAT32 maxed out at 4GB. So, when saving images, I need to compress it to less than 4GB. Needless, to say, I'm not happy!

I will not repartition my SD card without back up. I will get a 32 GB card, and see if I can back up into that, then I will repartition that card into 4GB chunk partition. Then, I will write the script to back up with compression. Hopefully, that will work just fine.

I found out that there is no swap partition, though. There's NOOBS partition, boot partition, and main partition. There is something about 2 MB, but I don't know what it is. Never mind. My next card will have 4 GB partitions all around. I hope that I have enough space for /usr/bin. I'll be installing quite a bit of software. My Robo3D printer just came in, and I'll be hooking it up to Raspberry Pi, for sure!