Keeping Up with Python: the 2.2 Release
Generators extend from the idea of iterators. The main motivation for generators, however, comes from a different angle: they allow saving state across function calls. Static variables, such as in C functions, have the ability to maintain their value across multiple calls of that function. This partially solves the state problem, but what would be really nice would be to yield a value just like an iterator but be able to freeze execution only to resume exactly where you left off when it is called again. This is exactly what generators do. They represent the idea of merging iteration with state along with functions that are resumable. When they do, they pick up right where they left off, keeping intact all the state information they need to deliver the next item. Note that we use the term yield here for two reasons: to hint that it's not a true return (along with frame object stack pop) and to introduce the new keyword yield.
For backward compatibility (in case there is code out there that uses yield as an identifier), you must include the “from __future__ import generators” directive to use generators. Generators will become standard soon (2.3?) so importing will not be a necessity. Generators behave in another manner similar to iterators: when a real return or end-of-function is reached and there are no more values to yield, a StopIteration exception is raised. Here's a simple example:
def simpleGen(): yield 1 yield '2 --> punch!'
Now that we have our function, let's call it and get a generator object:
>>> myG = simpleGen() >>> myG.next() 1 >>> myG.next() '2 --> punch!' >>> myG.next() Traceback (most recent call last): File "", line 1, in ? myG.next() StopIterationor more aptly: for eachItem in simpleGen(): print eachItem. Of course that was a silly example. I mean, why not use a real iterator for that? More motivation comes from being able to iterate through a sequence that requires the power of a function, rather than static objects already sitting in some sequence.
In the following example, we are going to create a random iterator that takes a sequence and returns a random item from that sequence:
from random import randint def randIter(seq): while len(seq) > 0: yield seq.pop(randint(0, len(seq)-1))
The difference is that each item returned is also consumed from that sequence, sort of like a combination of list.pop() and random.choice():
>>> for eachItem in randIter([123, 'xyz', 45.678, 9j]): ... print eachItem ... 'xyz' 9j 45.678 123Table 1 is a summary of the differences between iterators and generators. You can find more details on both iterators and generators in their respective PEPs (234 and 255).
This is perhaps the most controversial update to Python so far. There are many pros and cons, but finally those who believe in true division have won out. To highlight this change let's define (or redefine) some division terms and their functionality with integer and floating-point operands.
When presented with integer operands, classic division truncates the decimal place, returning an integer (see the “Floor Division” section below). When given a pair of floating-point operands, it returns the actual floating-point quotient (see the “True Division” section). Here is an example of what Python's division has been and still is today (actually a mix of true and floor division):
>>> 1 / 2 # perform integer result (floor) 0 >>> 1.0 / 2.0 # returns real quotient 0.5
This is the case where the result should always be the actual quotient, regardless of the type of the operands. This is the big change that is to come our way when Python 3.0 nears reality. For now, to take advantage of true division, one must give the from __future__ import division directive. Once that happens, the division operator ( / ) performs only true division:
>>> from __future__ import division >>> >>> 1 / 2 # returns real quotient 0.5 >>> 1.0 / 2.0 # returns real quotient 0.5
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!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SourceClear Open
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
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