Iterators & Generators -3
Itertools
The itertools module in the standard library provides lot of intersting tools to work with iterators.Lets look at some of the interesting functions.
chain – chains multiple iterators together.
>>> it1 = iter([1, 2, 3])
>>> it2 = iter([4, 5, 6])
>>> itertools.chain(it1, it2)
[1, 2, 3, 4, 5, 6]
>>> for x, y in itertools.izip(["a", "b", "c"], [1, 2, 3]):
... print x, y
...
a 1
b 2
c 3
>>> it = iter(range(5))
>>> x, it1 = peep(it)
>>> print x, list(it1)
0 [0, 1, 2, 3, 4]
>>> list(enumerate(["a", "b", "c"])
[(0, "a"), (1, "b"), (2, "c")]
>>> for i, c in enumerate(["a", "b", "c"]):
... print i, c
...
0 a
1 b
2 c
Iterators & Generators -2
Generators
Generators simplifies creation of iterators. A generator is a function that produces a sequence of results instead of a single value.def yrange(n):
i = 0
while i < n:
yield i
i += 1
>>> y = yrange(3)
>>> y
<generator object yrange at 0x401f30>
>>> y.next()
0
>>> y.next()
1
>>> y.next()
2
>>> y.next()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
StopIteration
The word “generator” is confusingly used to mean both the function that generates and what it generates. In this chapter, I’ll use the word “generator” to mean the genearted object and “generator function” to mean the function that generates it.
Can you think about how it is working internally?
When a generator function is called, it returns an generator object without even beginning execution of the function. When next` method is called for the first time, the function starts executing until it reaches yield statement. The yielded value is returned by the next call.
The following example demonstrates the interplay between yield and call to next method on generator object.
>>> def foo():
... print "begin"
... for i in range(3):
... print "before yield", i
... yield i
... print "after yield", i
... print "end"
...
>>> f = foo()
>>> f.next()
begin
before yield 0
0
>>> f.next()
after yield 0
before yield 1
1
>>> f.next()
after yield 1
before yield 2
2
>>> f.next()
after yield 2
end
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
StopIteration
>>>
def integers():
"""Infinite sequence of integers."""
i = 1
while True:
yield i
i = i + 1
def squares():
for i in integers():
yield i * i
def take(n, seq):
"""Returns first n values from the given sequence."""
seq = iter(seq)
result = []
try:
for i in range(n):
result.append(seq.next())
except StopIteration:
pass
return result
print take(5, squares()) # prints [1, 4, 9, 16, 25]
Iterators & Generators -1
Iterators
We use for statement for looping over a list.>>> for i in [1, 2, 3, 4]:
... print i,
...
1
2
3
4
>>> for c in "python":
... print c
...
p
y
t
h
o
n
>>> for k in {"x": 1, "y": 2}:
... print k
...
y
x
>>> for line in open("a.txt"):
... print line,
...
first line
second line
There are many functions which consume these iterables.
>>> ",".join(["a", "b", "c"])
'a,b,c'
>>> ",".join({"x": 1, "y": 2})
'y,x'
>>> list("python")
['p', 'y', 't', 'h', 'o', 'n']
>>> list({"x": 1, "y": 2})
['y', 'x']
Django
Django is a free and open source web application framework, written in Python, which follows the model–view–controller architectural pattern. It is maintained by the Django Software Foundation (DSF), an independent organization established as a 501(c)(3) non-profit.
Django's primary goal is to ease the creation of complex, database-driven websites. Django emphasizes reusability and "pluggability" of components, rapid development, and the principle of don't repeat yourself. Python is used throughout, even for settings, files, and data models. Django also provides an optional administrative create, read, update and delete interface that is generated dynamically through introspection and configured via admin models.
What Is a Web Framework?
Django is a prominent member of a new generation of Web frameworks – but what does that term mean, precisely?
To answer that question, let’s consider the design of a Web application written in Python without a framework. Throughout this book, we’ll take this approach of showing you basic ways of getting work done without shortcuts, in the hope that you’ll recognize why shortcuts are so helpful. (It’s also valuable to know how to get things done without shortcuts because shortcuts aren’t always available. And most importantly, knowing why things work the way they do makes you a better Web developer.)
One of the simplest, most direct ways to build a Python Web app from scratch is to use the Common Gateway Interface (CGI) standard, which was a popular technique circa 1998. Here’s a high-level explanation of how it works: just create a Python script that outputs HTML, then save the script to a Web server with a ”.cgi” extension and visit the page in your Web browser. That’s it.
Here’s an example Python CGI script that displays the ten most recently published books from a database. Don’t worry about syntax details; just get a feel for the basic things it’s doing:
#!/usr/bin/env python
import MySQLdb
print "Content-Type: text/html\n"
print "<html><head><title>Books</title></head>"
print "<body>"
print "<h1>Books</h1>"
print "<ul>"
connection = MySQLdb.connect(user='me', passwd='letmein', db='my_db')
cursor = connection.cursor()
cursor.execute("SELECT name FROM books ORDER BY pub_date DESC LIMIT 10")
for row in cursor.fetchall():
print "<li>%s</li>" % row[0]
print "</ul>"
print "</body></html>"
connection.close()
With a one-off page like this one, the write-it-from-scratch approach isn’t necessarily bad. For one thing, this code is simple to comprehend – even a novice developer can read these 16 lines of Python and understand everything it does, from start to finish. There’s nothing else to learn, no other code to read. It’s also simple to deploy: just save this code in a file that ends with ”.cgi”, upload that file to a Web server, and visit that page with a browser.
But despite its simplicity, this approach has a number of problems and annoyances. Ask yourself these questions:
- What happens when multiple parts of your application need to connect to the database? Surely that database-connecting code shouldn’t need to be duplicated in each individual CGI script. The pragmatic thing to do would be to refactor it into a shared function.
- Should a developer really have to worry about printing the “Content-Type” line and remembering to close the database connection? This sort of boilerplate reduces programmer productivity and introduces opportunities for mistakes. These setup- and teardown-related tasks would best be handled by some common infrastructure.
- What happens when this code is reused in multiple environments, each with a separate database and password? At this point, some environment-specific configuration becomes essential.
- What happens when a Web designer who has no experience coding Python wishes to redesign the page? One wrong character could crash the entire application. Ideally, the logic of the page – the retrieval of book titles from the database – would be separate from the HTML display of the page, so that a designer could edit the latter without affecting the former.
Simple way to create png image with an input text.
from PIL import Image
from PIL import ImageDraw
from PIL import ImageFont
from PIL import ImageFilterdef make_img(image, textColor, backgroundColor):
img = image.convert("RGBA")
img.putdata([textColor if value == 0 else backgroundColor
for value in image.getdata()])
return imgI use Arggotsc.ttf. You can use any TrueType font.
text = " Inca un script in python! "
font = ImageFont.truetype('Arggotsc.ttf', 55)
image = Image.new("1", font.getsize(text), '#FFF')draw = ImageDraw.Draw(image)
draw.text((0, 0), text, font=font)
image = image.resize([i for i in image.size], Image.NEAREST)
imgText = make_img(image, (200, 200, 200), (0, 0, 0, 0))
blur_img = make_img(image, (0, 0, 0), (0, 0, 0, 0))
for i in range(3):
blur_img = blur_img.filter(ImageFilter.BLUR)
blur_img.paste(imgText, (0, 0), imgText)
blur_img.save("text-img.png")
How to deal with environment variables using python script
Any OS like Linux, Unix, Windows has environment variables.
Also any variables which must not be committed on a public code can be used in this way.
You can give this variables to your application.
Let's see one simple example about how to do that:
import os
ENV_VAR = os.environ.get("ENV_VAR", None)
if not ENV_VAR:
print "not ENV_VAR"
if ENV_VAR:
print "yes ! is ENV_VAR"usertest@home:~$ ENV_VAR=true python demo-env.py
yes ! is ENV_VAR
usertest@home:~$ python demo-env.py
not ENV_VARA Brief History of Python
A Brief History of Pytho:
| Release Date | Version |
| December, 1989 | Implementation started |
| 1990 | Internal releases at CWI |
| February 20, 1991 | 0.9.0 (released to alt.sources) |
| February, 1991 | 0.9.1 |
| Autumn, 1991 | 0.9.2 |
| December 24, 1991 | 0.9.4 |
| January 2, 1992 | 0.9.5 (Macintosh only) |
| April 6, 1992 | 0.9.6 |
| Unknown, 1992 | 0.9.7beta |
| January 9, 1993 | 0.9.8 |
| July 29, 1993 | 0.9.9 |
| January 26, 1994 | 1.0.0 |
| February 15, 1994 | 1.0.2 |
| May 4, 1994 | 1.0.3 |
| July 14, 1994 | 1.0.4 |
| October 11, 1994 | 1.1 |
| November 10, 1994 | 1.1.1 |
| April 13, 1995 | 1.2 |
| October 13, 1995 | 1.3 |
| October 25, 1996 | 1.4 |
| January 3, 1998 | 1.5 |
| October 31, 1998 | 1.5.1 |
| April 13, 1999 | 1.5.2 |
| September 5, 2000 | 1.6 |
| October 16, 2000 | 2.0 |
| April 17, 2001 | 2.1 |
| December 21, 2001 | 2.2 |
| July 29, 2003 | 2.3 |
| November 30, 2004 | 2.4 |
| September 16, 2006 | 2.5 |
| October 1, 2008 | 2.6 |
| December 3, 2008 | 3.0 |
Python's Design Philosophy
Python's Design Philosophy
First of all, Python was originally conceived as a one-person “skunkworks” project – there was no official budget, and I wanted results quickly, in part so that I could convince management to support the project (in which I was fairly successful). This led to a number of timesaving rules:
- Borrow ideas from elsewhere whenever it makes sense.
- “Things should be as simple as possible, but no simpler.” (Einstein)
- Do one thing well (The "UNIX philosophy").
- Don’t fret too much about performance--plan to optimize later when needed.
- Don’t fight the environment and go with the flow.
- Don’t try for perfection because “good enough” is often just that.
- (Hence) it’s okay to cut corners sometimes, especially if you can do it right later.
- The Python implementation should not be tied to a particular platform. It’s okay if some functionality is not always available, but the core should work everywhere.
- Don’t bother users with details that the machine can handle (I didn’t always follow this rule and some of the of the disastrous consequences are described in later sections).
- Support and encourage platform-independent user code, but don’t cut off access to platform capabilities or properties (This is in sharp contrast to Java.)
- A large complex system should have multiple levels of extensibility. This maximizes the opportunities for users, sophisticated or not, to help themselves.
- Errors should not be fatal. That is, user code should be able to recover from error conditions as long as the virtual machine is still functional.
- At the same time, errors should not pass silently (These last two items naturally led to the decision to use exceptions throughout the implementation.)
- A bug in the user’s Python code should not be allowed to lead to undefined behavior of the Python interpreter; a core dump is never the user’s fault.
Although I will discuss more of ABC's influence on Python a little later, I’d like to mention one readability rule specifically: punctuation characters should be used conservatively, in line with their common use in written English or high-school algebra. Exceptions are made when a particular notation is a long-standing tradition in programming languages, such as “x*y” for multiplication, “a[i]” for array subscription, or “x.foo” for attribute selection, but Python does not use “$” to indicate variables, nor “!” to indicate operations with side effects.
Tim Peters, a long time Python user who eventually became its most prolific and tenacious core developer, attempted to capture my unstated design principles in what he calls the “Zen of Python.” I quote it here in its entirety:
- Beautiful is better than ugly.
- Explicit is better than implicit.
- Simple is better than complex.
- Complex is better than complicated.
- Flat is better than nested.
- Sparse is better than dense.
- Readability counts.
- Special cases aren't special enough to break the rules.
- Although practicality beats purity.
- Errors should never pass silently.
- Unless explicitly silenced.
- In the face of ambiguity, refuse the temptation to guess.
- There should be one-- and preferably only one --obvious way to do it.
- Although that way may not be obvious at first unless you're Dutch.
- Now is better than never.
- Although never is often better than right now.
- If the implementation is hard to explain, it's a bad idea.
- If the implementation is easy to explain, it may be a good idea.
- Namespaces are one honking great idea -- let's do more of those!
- The ABC group strived for perfection. For example, they used tree-based data structure algorithms that were proven to be optimal for asymptotically large collections (but were not so great for small collections).
- The ABC group wanted to isolate the user, as completely as possible, from the “big, bad world of computers” out there. Not only should there be no limit on the range of numbers, the length of strings, or the size of collections (other than the total memory available), but users should also not be required to deal with files, disks, “saving”, or other programs. ABC should be the only tool they ever needed. This desire also caused the ABC group to create a complete integrated editing environment, unique to ABC (There was an escape possible from ABC’s environment, for sure, but it was mostly an afterthought, and not accessible directly from the language.)
- The ABC group assumed that the users had no prior computer experience (or were willing to forget it). Thus, alternative terminology was introduced that was considered more “newbie-friendly” than standard programming terms. For example, procedures were called “how-tos” and variables “locations”.
- The ABC group designed ABC without an evolutionary path in mind, and without expecting user participation in the design of the language. ABC was created as a closed system, as flawless as its designers could make it. Users were not encouraged to “look under the hood”. Although there was talk of opening up parts of the implementation to advanced users in later stages of the project, this was never realized.
Python projects
Python projects
Python serves as an umbrella organization for around a dozen open source Python projects each year. This year, the following projects are participating:- CPython : core Python and the standard library
- GNU Mailman: the ubiquitous mailing list package
- Mercurial: a distributed source control management tool
- BinPy: a platform for building circuit-based applications or logical games
- Vispy: high-performance interactive visualizations
- TARDIS-SN: supernova radiative transfer in Python
- SunPy: Python for solar physics
- Scrapy: a fast, high-level screen scraping and web crawling framework
- Theano: an optimizing compiler for numpy.ndarray and scipy.sparse matrix
- Kivy: a library for making cross-platform, multi-touch apps
- MNE-Python: a software package for processing MEG and EEG data
- scikit-image: a collection of algorithms for image processing
- scikit-learn: a Python module for machine learning
- PyDy: a package for studying multibody dynamics with Python
- SciPy and NumPy: open-source software for mathematics, science, and engineering
- AstroPy: a community Python library for astronomy
Fixing Reeborg
Fixing Reeborg:
- I used the analogy of synonyms to talk about variables
- Students have already seen how to define new object [like Reeborg = UsedRobot()]
Fixing up Reeborg
As we have seen, we can create new robots by using the notationReeborg = UsedRobot() Erdna = UsedRobot(2, 2)However, these robots are just like the original nameless one: they
can only turn left. To teach them how to turn right, we could define
a function similar to what we did before:
def Reeborg_turn_right(): for i in range(3): Reeborg.turn_left()However, there are at least two problems with this approach:
- We need to define a similar function for every single robot we create (Reeborg, Erdna, ...).
- Reeborg and turn are separated by an underscore character "_" for the function we defined [to turn right] and by a dot "." for the built-in method [to turn left]. This would not look right...
what we do in the next section.
Designing a new class
I will show you first how we can fix our robot so that it knows how to turn right, and explain what I did afterwords.
class RepairedRobot(UsedRobot): def turn_right(synonym_used_to_refer_to_this_object): for i in range(3): synonym_used_to_refer_to_this_object.turn_left()Here's how we can then use this new class of objects:
newReeborg = RepairedRobot() newErdna = RepairedRobot(2, 2) newReeborg.turn_left() # as before newReeborg.turn_right() # new method! newErdna.turn_right() # this one works too!And now, it is time to explain. The Python keyword class indicates that we are going to define a new type of "function", one that creates objects. What follows class is: RepairedRobot(UsedRobot).
RepairedRobot is the name of our new class; by writing UsedRobot between the parentheses, we ensure that the new class RepairedRobot inherits all the methods and attributes that UsedRobot had. Thus, when we write:
newReeborg = RepairedRobot()we create a new robot "named" newReeborg which can do (at least all) the same things that the old Reeborg = UsedRobot() could do.
Next, inside the new class, as indicated by the indented block, we define a new method, turn_right(). By defining it inside the class, we take the first step to insure that all the robots that are created by calling RepairedRobot() will be able to turn right!
The second step that is required is to tell Python that the method will "belong" to the particular object that has been created. To do so, we use the variable synonym_used_to_refer_to_this_object which will refer to newReeborg, newErdna, etc., depending on what object is created. When we write
newReeborg = RepairedRobot()Python creates a new instance of the class RepairedRobot and defines all the methods, replacing the first argument of the method (synonym_used_to_refer_to_this_object) by the name of the
instance (newReeborg).
Now, synonym_used_to_refer_to_this_object is rather a long name to type. By convention, another variable name is used: self. Thus, to follow the normal convention, I should have
written:
class RepairedRobot(UsedRobot): def turn_right(self): for i in range(3): self.turn_left()
List of files, directories in Python
A short python program that prints the list of all files
inside the current directory and subdirectories. It prints filename with
relative path to the current directory.
You can also print the list of directories only (just print the dirs). Actually I needed this stuff to solve a problem from Google treasure hunt. Let me know if you want me to share the full source code of the solutions of Google treasure hunt. Also share your code, if you have any different idea!
import os
for root, dirs, files in os.walk('./'):
for name in files:
filename = os.path.join(root, name)
print filename
You can also print the list of directories only (just print the dirs). Actually I needed this stuff to solve a problem from Google treasure hunt. Let me know if you want me to share the full source code of the solutions of Google treasure hunt. Also share your code, if you have any different idea!
calculate age from date of birth
calculate age from date of birth
this is the simple code for calculate age from date of birth
def calculate_age(born):
today = date.today()
try:
birthday = born.replace(year=today.year)
except ValueError: # raised when birth date is February 29 and the current year is not a leap year
birthday = born.replace(year=today.year, day=born.day-1)
if birthday > today:
return today.year - born.year - 1
else:
return today.year - born.year
if __name__ == "__main__":
day, month, year = [int(x) for x in "7/11/1982".split("/")]
born = date(year, month, day)
print calculate_age(born)
Python for begineer contents
Python for beginner contents
To the student: Why Python?
History-of-python.
what-is-python?
pythons-feature.
how-to-install-python?
very-simple-programs.
variables-scripts.
Loops&Conditionals.
The-for-loop
Lists
Tuple
python-object-oriented.
Dictionaries
Functions-1
Functions-2
modules.
Files-i/o
Exception-handling.
Python programs
programs.
python video tutorial
video tutorials.
The Python getattr Function
Python’s getattr function is used to fetch an attribute from
an object, using a string object instead of an identifier to identify the
attribute. In other words, the following two statements are equivalent:
value = obj.attribute
value = getattr(obj, "attribute")
If the attribute exists, the corresponding value is
returned. If the attribute does not exist, you get anAttributeError exception
instead.
The getattr function can be used on any object that supports
dotted notation (by implementing the__getattr__ method). This includes class
objects, modules, and even function objects.
path = getattr(sys, "path")
doc = getattr(len, "__doc__")
The getattr function uses the same lookup rules as ordinary
attribute access, and you can use it both with ordinary attributes and methods:
result = obj.method(args)
func = getattr(obj, "method")
result = func(args)
or, in one line:
result = getattr(obj, "method")(args)
Calling both getattr and the method on the same line can
make it hard to handle exceptions properly. To avoid confusing AttributeError
exceptions raised by getattr with similar exceptions raised inside the method,
you can use the following pattern:
try:
func =
getattr(obj, "method")
except AttributeError:
... deal with
missing method ...
else:
result =
func(args)
The function takes an optional default value, which is used
if the attribute doesn’t exist. The following example only calls the method if
it exists:
func = getattr(obj, "method", None)
if func:
func(args)
Here’s a variation, which checks that the attribute is
indeed a callable object before calling it.
func = getattr(obj, "method", None)
if callable(func):
func(args)
Overview of python.
Introduction:
Python is a popular, free, cross-platform,
open-source computer programming language that is in wide use. It has no
licensing restrictions that would prevent its use in commercial projects. It
has a rich set of libraries for scientific and technical applications. Support,
tutorials and documentation are widely available.
Python is one of a class of languages that
began as simple scripting languages but evolved over time to become more
powerful languages with compilers and libraries — Perl and Ruby are other
examples. To indicate the informal way they evolved, I call these
"bottom-up" languages. Each of them has advantages and drawbacks, but
like many technical issues, there is a snowball effect — as a language's
popularity increases, this motivates people to write application libraries and
dedicated development environments, which increases its popularity further.
Some will argue that this is a rather
uncivilized way to create computer languages, and a more formal,
"top-down" approach should produce better results. There are examples
of language designs like C, C++ and Java that have advantages in structure and
syntax because architecture and consistent design were (to some extent) considered
in advance of practical embodiments.
Why Python?
My
first look at Python was an accident, and I didn't much like what I saw at the
time. It was early 1997, and Mark Lutz's book Programming Python from O'Reilly
& Associates had recently come out. O'Reilly books occasionally land on my
doorstep, selected from among the new releases by some mysterious benefactor
inside the organization using a random process I've given up trying to
understand.
One
of them was Programming Python. I found this somewhat interesting, as I collect
computer languages. I know over two dozen general-purpose languages, write
compilers and interpreters for fun, and have designed any number of
special-purpose languages and markup formalisms myself. My most recently
completed project, as I write this, is a special-purpose language called SNG
for manipulating PNG (Portable Network Graphics) images. Interested readers can
surf to the SNG home page at http://www.catb.org/~esr/sng/. I have also written
implementations of several odd general-purpose languages on my Retrocomputing
Museum page, http://www.catb.org/retro/.
I
had already heard just enough about Python to know that it is what is nowadays
called a “scripting language”, an interpretive language with its own built-in
memory management and good facilities for calling and cooperating with other
programs. So I dived into Programming Python with one question uppermost in my
mind: what has this got that Perl does not?
Perl,
of course, is the 800-pound gorilla of modern scripting languages. It has
largely replaced shell as the scripting language of choice for system
administrators, thanks partly to its comprehensive set of UNIX library and
system calls, and partly to the huge collection of Perl modules built by a very
active Perl community. The language is commonly estimated to be the CGI
language behind about 85% of the “live” content on the Net. Larry Wall, its
creator, is rightly considered one of the most important leaders in the Open
Source community, and often ranks third behind Linus Torvalds and Richard
Stallman in the current pantheon of hacker demigods.
At
that time, I had used Perl for a number of small projects. I'd found it quite
powerful, even if the syntax and some other aspects of the language seemed
rather ad hoc and prone to bite one if not used with care. It seemed to me that
Python would have quite a hill to climb as yet another scripting language, so
as I read, I looked first for what seemed to set it apart from Perl.
I
immediately tripped over the first odd feature of Python that everyone notices:
the fact that whitespace (indentation) is actually significant in the language
syntax. The language has no analog of the C and Perl brace syntax; instead, changes
in indentation delimit statement groups. And, like most hackers on first
realizing this fact, I recoiled in reflexive disgust.
I am
just barely old enough to have programmed in batch FORTRAN for a few months
back in the 1970s. Most hackers aren't these days, but somehow our culture
seems to have retained a pretty accurate folk memory of how nasty those
old-style fixed-field languages were. Indeed, the term “free format”, used back
then to describe the newer style of token-oriented syntax in Pascal and C, has
almost been forgotten; all languages have been designed that way for decades
now. Or almost all, anyway. It's hard to blame anyone, on seeing this Python
feature, for initially reacting as though they had unexpectedly stepped in a
steaming pile of dinosaur dung.
Where is python Language used.
All
the languages you've mentioned are Turing Complete, so in theory there is
nothing one can do and another can't. In practice of course, there are
differences, especially in productivity and efficiency. Compared to C, C++ and
Java, which are static typed, Python is a dynamic language and can help you
write the same code in significantly fewer lines. Python has a moto
"batteries included", which means that the standard library offers
all the things needed to build a complex application. Other languages would need
external libraries for this. On top of this, since Python is an old and mature
language (older than Java), many external libraries (for game development and
scientific calculations just to mention a few) have been evolved. So Python can
be used to program desktop applications and in fact in some cases more
efficiently than other traditional languages.
Subscribe to:
Comments (Atom)