Programming Python, Part II
The tutorial in last month's issue covered the basics of installing Python, running it and using it. Then, we moved on to building a basic blog in Python. The blog was extremely simple—only a Python list. We focused on the posts and built a Post class:
class Post(object): def __init__(self, title, body): self.set_title(title) self.set_body(body) def set_title(self, title): self._title = title def get_title(self): return self._title def set_body(self, body): self._body = body def get_body(self): return self._body def __repr__(self): return "Blog Post: %s" % self.get_title()
In this follow-up article, let's focus on the blog itself and go further.
Now that we have the Post class, we can make the Blog class. An initial implementation may look like this:
class Blog(object): def __init__(self): self._posts =  def add_post(self, post): self._posts.append(post) def get_posts(self): return self._posts
We are using a list to maintain the posts, but the interface is totally abstract behind a set of methods in the Blog class. This has a huge advantage: tomorrow we could replace that simple list with an SQL back end, and the code that uses Blog will need few, if any, changes.
Notice that there's no way to delete a post. We could tamper with _posts directly, but as long as we do what the class was meant to do, we can't delete a post. That may be good or bad, but the important thing is that by defining a set of methods, we exposed the design of how the class should be used.
The method get_posts returns all the posts. When we are writing a new post, we don't want the whole world to be able to read it until it is finished. The posts need a new member that tell whether it is published. In Post's initalizator, __init__, we add the line:
self._published = False
That makes every new post private by default. To switch states, we add the methods:
def publish(self): self._published = True def hide(self): self._published = False def is_public(self): return self._published
In these methods, I introduced a new kind of variable—the boolean. Booleans are simple; they can be true or false. Let's play with that a bit:
>>> cool = blog.Post("Cool", "Python is cool") >>> cool.is_public() False >>> cool.publish() >>> cool.is_public() True >>> cool.hide() >>> cool.is_public() False >>>
If, when you run is_public, you get:
Traceback (most recent call last): File "<stdin>", line 1, in ? File "blog.py", line 25, in is_public return self._published AttributeError: 'Post' object has no attribute '_published'
That's because _published was not created, it can't be used, and is_public wants to use it. Understanding errors in your tools is important if you want to be a successful programmer.
In this short set of messages, the last line is the error itself. There are various types of errors, and this one is an AttributeError. A lot of important information is given in the traceback. A traceback is a list of “who called whom”, providing an idea of what was being executed when the error occurred.
The first line of the traceback doesn't give much information. It probably relates to the line we typed at the REPL. The second line tells that the error was in the file blog.py, on line 25, on the method is_public. Now we have the line that raised the problem.
This traceback is simple. In a real application, you would have methods that call methods that call methods and so on. In those cases, it is not uncommon to see tracebacks of 25 lines or more. I've seen tracebacks of more than 150 lines, but those were extreme cases in extreme conditions.
The next step is a modification to the Blog class to pick up only published posts. So, we add a new method:
def get_public_posts(self): published_posts =  for post in self._posts: if port.is_public(): published_posts.append(post)
Python tries to be as readable as possible, but that method introduces too many new things, so it requires some careful explanations.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- Linux In Government: Interoperability
- Linux in Government: Winning in the Big Enterprise Space
- Linux in Government: Open Source Innovation within the DoD
- Linux in Government: An Interview with John Weathersby of OSSI
- Linux in Government: GNU/Linux Clears Procurement Hurdles
- Convert Filenames to Lowercase
- Tech Tip: Really Simple HTTP Server with Python
- Getting Started with Salt Stack-the Other Configuration Management System Built with Python
- Concerning Containers' Connections: on Docker Networking
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide