diff options
Diffstat (limited to 'pypers/preface.tex')
| -rwxr-xr-x | pypers/preface.tex | 832 |
1 files changed, 832 insertions, 0 deletions
diff --git a/pypers/preface.tex b/pypers/preface.tex new file mode 100755 index 0000000..b298225 --- /dev/null +++ b/pypers/preface.tex @@ -0,0 +1,832 @@ +\documentclass[11pt,english]{book} +\usepackage{babel} +\usepackage{shortvrb} +\usepackage[latin1]{inputenc} +\usepackage{tabularx} +\usepackage{longtable} +\setlength{\extrarowheight}{2pt} +\usepackage{amsmath} +\usepackage{graphicx} +\usepackage{color} +\usepackage{multirow} +\usepackage[colorlinks=true,linkcolor=blue,urlcolor=blue]{hyperref} +\usepackage[a4paper,margin=2cm]{geometry} +%% generator Docutils: http://docutils.sourceforge.net/ +\newlength{\admonitionwidth} +\setlength{\admonitionwidth}{0.9\textwidth} +\newlength{\docinfowidth} +\setlength{\docinfowidth}{0.9\textwidth} +\newcommand{\optionlistlabel}[1]{\bf #1 \hfill} +\newenvironment{optionlist}[1] +{\begin{list}{} + {\setlength{\labelwidth}{#1} + \setlength{\rightmargin}{1cm} + \setlength{\leftmargin}{\rightmargin} + \addtolength{\leftmargin}{\labelwidth} + \addtolength{\leftmargin}{\labelsep} + \renewcommand{\makelabel}{\optionlistlabel}} +}{\end{list}} +% begin: floats for footnotes tweaking. +\setlength{\floatsep}{0.5em} +\setlength{\textfloatsep}{\fill} +\addtolength{\textfloatsep}{3em} +\renewcommand{\textfraction}{0.5} +\renewcommand{\topfraction}{0.5} +\renewcommand{\bottomfraction}{0.5} +\setcounter{totalnumber}{50} +\setcounter{topnumber}{50} +\setcounter{bottomnumber}{50} +% end floats for footnotes +% some commands, that could be overwritten in the style file. +\newcommand{\rubric}[1]{\section*{~\hfill {\it #1} \hfill ~}} +% end of "some commands" +\input{/mnt/exp/MyDocs/pypers/style.tex} +\title{OBJECT ORIENTED PROGRAMMING IN PYTHON} +\author{} +\date{} +\hypersetup{ +pdftitle={OBJECT ORIENTED PROGRAMMING IN PYTHON}, +pdfauthor={Michele Simionato} +} +\raggedbottom +\begin{document} +\maketitle + +%___________________________________________________________________________ +\begin{center} +\begin{tabularx}{\docinfowidth}{lX} +\textbf{Version}: & + 0.5 \\ +\textbf{Author}: & + Michele Simionato \\ +\textbf{E-mail}: & + mis6@pitt.edu \\ +\textbf{Home-page}: & + http://www.phyast.pitt.edu/~micheles/ \\ +\textbf{Disclaimer}: & + I release this book to the general public. +It can be freely distributed if unchanged. +As usual, I don't give any warranty: while I have tried hard to ensure the +correctness of what follows, I disclaim any responsability in case of +errors . Use it at your own risk and peril ! \\ +\end{tabularx} +\end{center} + + + +\tableofcontents + +\bigskip +\setcounter{chapter}{-1} + +%___________________________________________________________________________ + +\hypertarget{preface}{} +\chapter{Preface} +\begin{quote} +\begin{flushleft} +\emph{There~is~only~one~way~to~learn:~trough~examples} +\end{flushleft} +\end{quote} + + +%___________________________________________________________________________ + +\hypertarget{the-philosophy-of-this-book}{} +\section{The philosophy of this book} + +This book is written with the intent to help the programmer going trough +the fascinating concepts of Object Oriented Programming (OOP), in their +Python incarnation. Notice that I say to help, not to teach. Actually, +I do not think that a book can teach OOP or any other non-trivial matter +in Computer Science or other disciplines. Only the +practice can teach: practice, then practice, and practice again. +You must learn yourself from your experiments, not from the books. +Nevertheless, books are useful. They cannot teach, but they can help. +They should give you new ideas that you was not thinking about, they should +show tricks you do not find in the manual, and in general they should be of +some guidance in the uphill road to knowledge. That is the philosophy +of this book. For this reason + +1. It is not comprehensive, not systematic; +it is intended to give ideas and basis: from +that the reader is expected to cover the missing part on his own, +browsing the documentation, other sources and other books, and finally +the definite autority, the source itself. + +2. It will not even try to teach the \emph{best} practices. I will show what you can +do with Python, not what you ``should'' do. Often I will show solutions that are +not recommended. I am not a mammy saying this is +good, this is bad, do this do that. + +3. You can only learn from your failures. If you think ``it should work, if I do +X and Y'' and it works, then you have learned nothing new. +You have merely verified +that your previous knowledge was correct, but you haven't create a new +knowledge. On the other hand, when you think ``it should work, if I do +X and Y'' and it doesn't, then you have learned that your previous knowlegde +was wrong or incomplete, and you are forced to learn something new to +overcome the difficulty. For this reason, I think it is useful to report +not only how to do something, but also to report how not to do something, +showing the pitfalls of wrong approaches. + +That's in my opinion is the goal of a good book. I don't know if have +reached this goal or not (the decision is up to the reader), but at least +I have tried to follow these guidelines. + +Moreover, this is not a book on OOP, +it is a book on OOP \emph{in Python}. + +In other words, the point of view of this book is not +to emphasize general topics of OOP that are exportable to other languages, +but exactly the opposite: I want to emphasize specific techniques that one +can only use in Python, or that are difficult to translate to other +languages. Moreover, I will not provide comparisons with other +languages (except for the section ``Why Python?'' in this introduction and +in few selected other places), +in order to keep the discussion focused. + +This choice comes from the initial motivation for this book, which was +to fulfill a gap in the (otherwise excellent) Python documentation. +The problem is that the available documentation still lacks an accessible +reference of the new Python 2.2+ object-oriented features. +Since myself I have learned Python and OOP from scratch, +I have decided to write this book in order to fill that gap and +help others. + +The emphasis in this book is not in giving +solutions to specific problems (even if most of the recipes of this book +can easily be tailored to solve real life concrete problems), it is in +teaching how does it work, why it does work in some cases and why does +not work in some other cases. Avoiding too specific problems has an +additional bonus, since it allows me to use \emph{short} examples (the majority +of the scripts presented here is under 20-30 lines) which I think are +best suited to teach a new matter [\hyperlink{id2}{1}] . Notice, however, that whereas +the majority of the scripts in this book are short, it is also true +that they are pretty \emph{dense}. The density is due to various reasons: +\newcounter{listcnt1} +\begin{list}{\arabic{listcnt1}.} +{ +\usecounter{listcnt1} +\setlength{\rightmargin}{\leftmargin} +} +\item +I am defining a lot of helper functions and classes, that are +reused and enhanced during all the book. + +\item +I am doing a strong use of inheritance, therefore a script at the +end of the book can inherits from the classes defined through all +the book; + +\item +A ten line script involving metaclasses can easily perform the equivalent +of generating hundreds of lines of code in a language without metaclasses +such as Java or C++. + +\end{list} + +To my knowledge, there are no other books covering the same topics with +the same focus (be warned, however, that I haven't read so many Python +books ;-). The two references that come closest to the present book are +the \texttt{Python Cookbook} by Alex Martelli and David Ascher, and +Alex Martelli's \texttt{Python in a Nutshell}. They are quite recent books and +therefore it covers (in much less detail) some of the 2.2 features that are +the central topics to this book. +However, the Cookbook reserves to OOP only one chapter and has a quite +different philosophy from the present book, therefore there is +practically no overlapping. Also \texttt{Python in a Nutshell} covers +metaclasses in few pages, whereas half of this book is essentially +dedied to them. This means that you can read both ;-) +\begin{figure}[b]\hypertarget{id2}[1] +Readers that prefer the opposite philosophy of using longer, +real life-like, examples, have already the excellent ``Dive into +Python'' book \href{http://diveintopython.org/}{http://diveintopython.org/} at their disposal. This is +a very good book that I certainly recommend to any (experienced) +Python programmer; it is also freely available (just like this ;-). +However, the choice of arguments is quite different and there is +essentially no overlap between my book and ``Dive into Python'' +(therefore you can read both ;-). +\end{figure} + + +%___________________________________________________________________________ + +\hypertarget{for-who-this-book-in-intended}{} +\section{For who this book in intended} + +I have tried to make this tutorial useful to a large public of Pythonistas, +i.e. both people with no previous experience of Object Oriented Programming +and people with experience on OOP, but unfamiliar with the most +recent Python 2.2-2.3 features (such as attribute descriptors, +metaclasses, change of the MRO in multiple inheritance, etc). +However, this is not a book for beginners: the non-experienced reader should +check (at least) the Internet sites www.python.org/newbies.com and +www.awaretek.com, that provide a nice collection of resources for Python +newbies. + +These are my recommendations for the reader, according to her/his level: +\newcounter{listcnt2} +\begin{list}{\arabic{listcnt2}.} +{ +\usecounter{listcnt2} +\setlength{\rightmargin}{\leftmargin} +} +\item +If you are an absolute beginner, with no experience on programming, +this book is \emph{not} for you (yet ;-). Go to +\href{http://www.python.org/doc/Newbies.html}{http://www.python.org/doc/Newbies.html} and read one of the introductive +texts listed there, then come back here. I recommend ``How to Think Like +a Computer Scientist'', available for free on the net (see +\href{http://www.ibiblio.org/obp/thinkCSpy/}{http://www.ibiblio.org/obp/thinkCSpy/}); I found it useful myself when +I started learning Python; be warned, however, that it refers to the rather +old Python version 1.5.2. There are also excellent books +on the market (see \href{http://www.awaretek.com/plf.html}{http://www.awaretek.com/plf.html}). +\href{http://www.uselesspython.com/}{http://www.uselesspython.com/} is a good resource to find recensions +about available Python books. For free books, look at +\href{http://www.tcfb.com/freetechbooks/bookphyton.html}{http://www.tcfb.com/freetechbooks/bookphyton.html} . +This is \emph{not} another Python tutorial. + +\item +If you know already (at least) another programming language, but you don't +know Python, then this book is \emph{not} for you (again ;-). Read the FAQ, the +Python Tutorial and play a little with the Standard Library (all this +material can be downloaded for free from \href{http://www.python.org}{http://www.python.org}), then +come back here. + +\item +If you have passed steps 1 and 2, and you are confortable with Python +at the level of simple procedural programming, but have no clue about +objects and classes, \emph{then} this book is for you. Read this book till +the end and your knowledge of OOP will pass from zero to a quite advanced +level (hopefully). Of course, you will have to play with the code in +this book and write a lot of code on your own, first ;-) + +\item +If you are confortable with Python and you also known OOP from other +languages or from earlier version of Python, then this book is for +you, too: you are ready to read the more advanced chapters. + +\item +If you are a Python guru, then you should read the book, too. I expect +you will find the errors and send me feedback, helping me to improve +this tutorial. + +\end{list} + + +%___________________________________________________________________________ + +\hypertarget{about-the-scripts-in-this-book}{} +\section{About the scripts in this book} + +All the scripts in this book are free. You are expected to play +with them, to modify them and to improve them. + +In order to facilitate the extraction of the scripts from the main text, both +visually for the reader and automatically for Python, I use the +convention of sandwiching the body of the example scripts in blocks like this +\begin{quote} +\begin{ttfamily}\begin{flushleft} +\mbox{{\#}{$<$}myfirstscript.py{$>$}}\\ +\mbox{}\\ +\mbox{print~"Here~Starts~the~Python~Way~to~Object~Oriented~Programming~!"}\\ +\mbox{}\\ +\mbox{{\#}{$<$}/myfirstscript.py{$>$}} +\end{flushleft}\end{ttfamily} +\end{quote} + +You may extract the source of this script with the a Python program +called ``test.py'' and provided in the distribution. Simply give the +following command: +\begin{quote} +\begin{ttfamily}\begin{flushleft} +\mbox{{\$}~python~test.py~myfirstscript.py} +\end{flushleft}\end{ttfamily} +\end{quote} + +This will create a file called ``myfirstscript.py'', containing the +source of \texttt{myfirstscript.py}; moreover it will execute the script +and write its output in a file called ``output.txt''. I have tested +all the scripts in this tutorial under Red Hat Linux 7.x and +Windows 98SE. You should not have any problem in running them, +but if a problem is there, ``test.py'' will probably discover it, +even if, unfortunately, it will not provide the solution :-(. +Notice that test.py requires Python 2.3+ to work, since most of +the examples in this book heavily depends on the new features +introduced in Python 2.2-2.3. Since the installation of Python +2.3 is simple, quick and free, I think I am requiring to my readers +who haven't upgraded yet a very little effort. This is well worth +the pain since Python 2.3 fixes few bugs of 2.2 (notably in the subject of +attribute descriptors and the \texttt{super} built-in) that makes + +You may give more arguments to test.py, as in this example: +\begin{quote} +\begin{ttfamily}\begin{flushleft} +\mbox{{\$}~python~test.py~myfirstscript.py~mysecondscript.py} +\end{flushleft}\end{ttfamily} +\end{quote} + +The output of both scripts will still be placed in the file ``output.txt''. +Notice that if you give an argument which is not the name of a script in the +book, it will be simply ignored. Morever, if you will not give any argument, +``test.py'' will automatically executes all the tutorial scripts, writing their +output in ``output.txt'' [\hyperlink{id4}{2}] . You may want to give a look at this file, once +you have finished the tutorial. It also contains the source code of +the scripts, for better readability. + +Many examples of this tutorial depend on utility functions defined +in a external module called \texttt{oopp} (\texttt{oopp} is an obvious abbreviation +for the title of the tutorial). The module \texttt{oopp} is automatically generated +by ``test.py'', which works by extracting from the tutorial +text blocks of code of the form \texttt{{\#}{$<$}oopp.py{$>$} something {\#}{$<$}/oopp.py{$>$}} +and saving them in a file called ``oopp.py''. +Let me give an example. A very recent enhancement to Python (in +Python 2.3) has been the addition of a built-in boolean type with +values True and False: +\begin{quote} +\begin{ttfamily}\begin{flushleft} +\mbox{{\$}~python}\\ +\mbox{Python~2.3a1~({\#}1,~Jan~~6~2003,~10:31:14)}\\ +\mbox{[GCC~2.96~20000731~(Red~Hat~Linux~7.2~2.96-108.7.2)]~on~linux2}\\ +\mbox{Type~"help",~"copyright",~"credits"~or~"license"~for~more~information.}\\ +\mbox{{$>$}{$>$}{$>$}~1+1==2}\\ +\mbox{True}\\ +\mbox{{$>$}{$>$}{$>$}~1+1==3}\\ +\mbox{False}\\ +\mbox{{$>$}{$>$}{$>$}~type(True)}\\ +\mbox{{$<$}type~'bool'{$>$}}\\ +\mbox{{$>$}{$>$}{$>$}~type(False)}\\ +\mbox{{$<$}type~'bool'{$>$}} +\end{flushleft}\end{ttfamily} +\end{quote} + +However, previous version of Python use the integers 1 and 0 for +True and False respectively. +\begin{quote} +\begin{ttfamily}\begin{flushleft} +\mbox{{\$}~python}\\ +\mbox{Python~2.2~({\#}1,~Apr~12~2002,~15:29:57)}\\ +\mbox{[GCC~2.96~20000731~(Red~Hat~Linux~7.2~2.96-109)]~on~linux2}\\ +\mbox{Type~"help",~"copyright",~"credits"~or~"license"~for~more~information.}\\ +\mbox{{$>$}{$>$}{$>$}~1+1==2}\\ +\mbox{1}\\ +\mbox{{$>$}{$>$}{$>$}~1+1==3~}\\ +\mbox{0} +\end{flushleft}\end{ttfamily} +\end{quote} + +Following the 2.3 convension, in this tutorial I will use the names +\texttt{True} and \texttt{False} to denotes the numbers 1 and 0 respectively. +This is automatic in Python 2.2.1+, but not in Python 2.2. Therefore, +for sake of compatibility, it is convenient to set the values \texttt{True} +and \texttt{False} in our utility module: +\begin{quote} +\begin{ttfamily}\begin{flushleft} +\mbox{{\#}{$<$}oopp.py{$>$}}\\ +\mbox{}\\ +\mbox{import~{\_}{\_}builtin{\_}{\_}}\\ +\mbox{try:~}\\ +\mbox{~~~~{\_}{\_}builtin{\_}{\_}.True~~~{\#}look~if~True~is~already~defined}\\ +\mbox{except~AttributeError:~{\#}~if~not~add~True~and~False~to~the~builtins}\\ +\mbox{~~~~{\_}{\_}builtin{\_}{\_}.True~=~1}\\ +\mbox{~~~~{\_}{\_}builtin{\_}{\_}.False~=~0}\\ +\mbox{}\\ +\mbox{{\#}{$<$}/oopp.py{$>$}} +\end{flushleft}\end{ttfamily} +\end{quote} + +Here there is an example of usage: +\begin{quote} +\begin{ttfamily}\begin{flushleft} +\mbox{{\#}{$<$}mysecondscript.py{$>$}}\\ +\mbox{}\\ +\mbox{import~oopp}\\ +\mbox{print~"True~=",True,}\\ +\mbox{print~"False~=",False}\\ +\mbox{}\\ +\mbox{{\#}{$<$}/mysecondscript.py{$>$}} +\end{flushleft}\end{ttfamily} +\end{quote} + +The output is ``True = 1 False = 0'' under Python 2.2 and +``True = True False = False'' under Python 2.3+. +\begin{figure}[b]\hypertarget{id4}[2] +``test.py'', invoked without arguments, does not create '.py' files, +since I don't want to kludge the distribution with dozens of ten-line +scripts. I expect you may want to save only few scripts as standalone +programs, and cut and paste the others. +\end{figure} + + +%___________________________________________________________________________ + +\hypertarget{conventions-used-in-this-book}{} +\section{Conventions used in this book} + +Python expressions are denoted with monospaced fonts when in the text. +Sections marked with an asterisk can be skipped in a first reading. +Typically they have the purpose of clarifying some subtle point and +are not needed for the rest of the book. These sections are intended +for the advanced reader, but could confuse the beginner. +An example is the section about the difference between methods and +functions, or the difference between the inheritance constraint and +the metaclass constraint. + + +%___________________________________________________________________________ + +\hypertarget{introduction}{} +\chapter{Introduction} +\begin{quote} +\begin{flushleft} +\emph{A~language~that~doesn't~affect~the~way~you~think~about~programming,~\\ +is~not~worth~knowing.}~--~Alan~Perlis +\end{flushleft} +\end{quote} + + +%___________________________________________________________________________ + +\hypertarget{why-oop}{} +\section{Why OOP ?} + +I guess some of my readers, like me, have started programming in the mid-80's, +when traditional (i.e. non object-oriented) Basic and Pascal where popular as +first languages. At the time OOP was not as pervasive in software development +how it is now, most of the mainstream languages were non-object-oriented and +C++ was just being released. That was a time when the transition from +spaghetti-code to structured code was already well accomplished, but +the transition from structured programming to (the first phase of) +OOP was at the beginning. + +Nowaydays, we live in a similar time of transition . Today, the transition +to (the first phase of) OOP is well accomplished and essentially all +mainstream +languages support some elementary form of OOP. To be clear, when I say +mainstream langauges, I have in mind Java and C++: C is a remarkable +exception to the rule, since it is mainstream but not object-oriented. + +However, both Java an C++ (I mean standard Java and C++, not special +extension like DTS C++, that have quite powerful object oriented features) +are quite poor object-oriented languages: they provides only the most +elementary aspects of OOP, the features of the \emph{first phase} of OOP. + +Hence, today the transition to the \emph{second phase} of OOP is only at the +beginning, i.e mainstream language are not yet really OO, but they will +become OOP in the near future. + +By second phase of OOP I mean the phase in which the primary +objects of concern for the programmer are no more the objects, but the +metaobjects. In elementary OOP one works on objects, which have attributes +and methods (the evolution of old-fashioned data and functions) defined +by their classes; in the second phase of OOP one works on classes +which behavior is described by metaclasses. We no more modify objects +trough classes: nowadays we modify classes and class hierarchies +through metaclasses and multiple inheritance. + +It would be tempting to represent the history of programming in the last +quarter of century with an evolutionary table like that: + +\begin{longtable}[c]{|p{0.28\linewidth}|p{0.23\linewidth}|p{0.26\linewidth}|p{0.08\linewidth}|} +\hline +\textbf{ +{\~{ }}1975 +} & \textbf{ +{\~{ }}1985 +} & \textbf{ +{\~{ }}1995 +} & \textbf{ +{\~{ }}2005 +} \\ \hline +\endhead +%[visit_tbody] + +procedural programming + & +OOP1 + & +OOP2 + & +? + \\ \hline + +data,functions + & +objects,classes + & +classes,metaclasses + & +? + \\ \hline +%[depart_tbody] +\end{longtable} + +The problem is that table would be simply wrong, since in truth +Smalltalk had metaclasses already 25 years ago! And also Lisp +had \emph{in nuce} everything a long \emph{long} time ago. +The truth is that certains languages where too much ahead of their +time ;-) + +Therefore, today we already have all the ideas +and the conceptual tools to go beyond the first phase of OOP +(they where invented 20-30 years ago), nevertheless those ideas are +not yet universally known, nor implemented in mainstream languages. + +Fortunately, there are good languages +where you can access the bonus of the second phase of OOP (Smalltalk, CLOS, +Dylan, ...): unfortunately +most of them are academic and/or little known in the real world +(often for purely commercial reasons, since typically languages are not +chosen accordingly to their merits, helas!). Python is an exception to this +rule, in the sense that it is an eminently practical language (it started +as a scripting language to do Operating System administrative jobs), +which is relatively known and used in that application niche (even if some +people \emph{wrongly} think that should not be used for 'serious' things). + +There are various reasons why most mainstream languages are rather +poor languages, i.e. underfeatured languages (as Java) or powerful, but too +tricky to use, as C++. Some are good reasons (for instance \emph{efficiency}: if +efficiency is the first concern, then poor languages can be much +better suited to the goal: for instance Fortran for number crunching +and C for system programming), some are less good (economical +monopoly). There is nothing to do against these reasons: if you +need efficiency, or if you are forced to use a proprietary language +because it is the language used by your employer. However, if you +are free from these restrictions, there is another reason why you +could not choose to use a poweful language. The reason is that, +till now, programmers working in the industrial world mostly had simple +problems (I mean conceptually simple problems). In order to solve +simple problems one does not need a powerful language, and the effort +spent in learning it is not worth. + +However, nowadays the situations has changed. Now, with Internet and graphics +programming everywhere, and object-oriented languages so widespread, +now it is the time when actually people \emph{needs} metaprogramming, the +ability to changing classes and programs. Now everybody is programming +in the large. + +In this situation, it is justified to spend some time to learn better +way of programming. And of course, it is convenient to start from +the language with the flattest learning curve of all. + + +%___________________________________________________________________________ + +\hypertarget{why-python}{} +\section{Why Python ?} +\begin{quote} +\begin{flushleft} +\emph{In~many~ways,~it's~a~dull~language,~borrowing~solid~old~concepts~from~~\\ +many~other~languages~{\&}~styles:~~boring~syntax,~unsurprising~semantics,~\\ +few~automatic~coercions,~etc~etc.~~But~that's~one~of~the~things~I~like~\\ +about~it.}~~--Tim~Peters~on~Python,~16~Sep~93 +\end{flushleft} +\end{quote} + +If you are reading this book, I assume you already have some experience +with Python. If this is the case, you already know the obvious advantages +of Python such as readability, easy of use and short development time. +Nevertheless, you could only have used Python as a fast and simple +scripting language. If you are in this situation, then your risk to +have an incorrect opinion on the language like ``it is a nice little +language, but too simple to be useful in 'real' applications''. The +truth is that Python is designed to be \emph{simple}, and actually it +is; but by no means it is a ``shallow'' language. Actually, it goes +quite \emph{deep}, but it takes some time to appreciate this fact. + +Let me contrast Python with Lisp, for instance. From the beginning, +Lisp was intended to be a language for experts, for people with difficult +problems to solve. The first +users of Lisp were academicians, professors of CS and scientists. +On the contrary, from the beginning Python +was intended to be language for everybody (Python predecessor was ABC, +a language invented to teach CS to children). Python makes great a first +language for everybody, whereas Lisp would require especially +clever and motivated students (and we all know that there is lack +of them ;-) + +From this difference of origins, Python inherits an easy to learn syntax, +whereas Lisp syntax is horrible for the beginner (even if not as +horrible as C++ syntax ;-) +\begin{quote} +\begin{flushleft} +\emph{Macros~are~a~powerful~extension~to~weak~languages.~\\ +Powerful~languages~don't~need~macros~by~definition.}~~\\ +--~Christian~Tismer~on~c.l.p.~(referring~to~C) +\end{flushleft} +\end{quote} + +Despite the differences, Python borrows quite a lot from Lisp and it +is nearly as expressive as it (I say nearly since Python is +not as powerful as Lisp: by tradition, Lisp has always been on the top of +hierarchy of programming language with respect to power of abstraction). +It is true that Python lacks some powerful Lisp features: for instance +Python object model lacks multiple dispatching (for the time being ;-) +and the language lacks Lisp macros (but this unlikely to change in the +near future since Pythonistas see the lack of macro as a Good Thing [\hyperlink{id6}{3}]): +nevertheless, the point is that Python is much \emph{much} easier to learn. +You have (nearly) all the power, but without the complexity. + +One of the reasons, is that Python +try to be as \emph{less} innovative as +possible: it takes the proven good things from others, more innovative +languages, and avoids their pitfalls. If you are an experienced +programmer , it will be even easier to you to learn Python, since +there is more or less nothing which is really original to Python. +For instance: +\newcounter{listcnt3} +\begin{list}{\arabic{listcnt3}.} +{ +\usecounter{listcnt3} +\setlength{\rightmargin}{\leftmargin} +} +\item +the object model is took from languages that are good at it, such +as Smalltalk; + +\item +multiple inheritance has been modeled from languages good in it. such +as CLOS and Dylan; + +\item +regular expression follows the road opened by Perl; + +\item +functional features are borrowed from functional languages; + +\item +the idea of documentation strings come from Lisp; + +\item +list comprehension come from Haskell; + +\item +iterators and generators come from Icon; + +\item +etc. etc. (many other points here) + +\end{list} + +I thinks the really distinctive feature of Python with respect to +any other serious language I know, is that Python is \emph{easy}. You have the +power (I mean power in conceptual sense, not computational power: in +the sense of computational power the best languages are +non-object-oriented ones) +of the most powerful languages with a very little investement. +In addition to that, Python has a relatively large user base +(as compared to Smalltalk or Ruby, or the various fragmented Lisp +communities). Of course, +there is quite a difference between the user base of Python with +respect to the user base of, let say, VisualBasic or Perl. But +I would never take in consideration VisualBasic for anything serious, +whereas Perl is too ugly for my taste ;-). +Finally, Python is \emph{practical}. With this I mean the fact that +Python has libraries that +allow the user to do nearly everything, since you can access all the C/C++ +libraries with little or no effort, and all the Java libraries, though the +Python implementation known as Jython. In particular, one has the choice +between many excellent GUI's trough PyQt, wxPython, Tkinter, etc. + +Python started as an Object Oriented Programming +Languages from the beginning, nevertheless is was never intended to be +a \emph{pure} OOPL as SmallTalk or, more recently, Ruby. Python is a +\emph{multiparadigm} +language such a Lisp, that you choose your programming style according +to your problem: spaghetti-code, structured programming, functional +programming, object-oriented programming are all supported. You can +even write bad code in Python, even if it is less simple than in other +languages ;-). Python is a language which has quite evolved in its twelve +years of life (the first public release was released in February 1991) +and many new features have been integrated in the language with time. +In particular, Python 2.2 (released in 2002) was a major breakthrough +in the history of the language +for what concerns support to Object Oriented Programming (OOP). +Before the 2.2 revolution, Python Object +Orientation was good; now it is \emph{excellent}. All the fundamental features +of OOP, including pretty sophisticated ones, as metaclasses and multiple +inheritance, have now a very good support (the only missing thing is +multiple dispatching). +\begin{figure}[b]\hypertarget{id6}[3] +Python lacks macros for an intentional design choice: many people +in the community (including Guido itself) feel that macros are +``too powerful''. If you give the user the freedom to create her +own language, you must face at least three problems: i) the risk +to split the original language in dozens of different dialects; +ii) in collaborative projects, the individual programmer must +spend an huge amount of time and effort would be spent in learning +macro systems written by others; iii) not all users are good +language designers: the programmer will have to fight with badly +designed macro systems. Due to these problems, it seems unlikely +that macros will be added to Python in the future. +\end{figure} +\begin{figure}[b]\hypertarget{id7}[4] +For a good comparison between Python and Lisp I remind the reader to +the excellent Peter Norvig's article in +\href{http://www.norvig.com/python-lisp.html}{http://www.norvig.com/python-lisp.html} +\end{figure} + + +%___________________________________________________________________________ + +\hypertarget{further-thoughts}{} +\section{Further thoughts} + +Actually, the principal reasons why I begun studying +Python was the documentation and the newsgroup: Python has an outstanding +freely available documentation and an incredibly helpful newsgroup that +make extremely easy to learn the language. If I had found a comparable +free documentation/newsgroup for C++ or Lisp, I would have studied that +languages instead. + +Unfortunately, the enormous development at the software level, had no +correspondence with with an appropriate development of documentation. +As a consequence, the many beatiful, powerful and extremely \emph{useful} +new features of Python 2.2+ object orientation are mostly remained +confined to developers and power users: the average Python programmer +has remained a little a part from the rapid development and she +\emph{wrongly} thinks she has no use for the new features. There have +also been \emph{protestations} of the users against developers of the +kind ``please, stop adding thousands of complicated new extensions +to the language for which we have no use'' ! + +Extending a language is always a delicate thing to do, for a whole +bunch of reasons: +\newcounter{listcnt4} +\begin{list}{\arabic{listcnt4}.} +{ +\usecounter{listcnt4} +\setlength{\rightmargin}{\leftmargin} +} +\item +once one extension is done, it is there \emph{forever}. + +\end{list} + +My experience has been the following. + +When I first read about metaclasses, in Guido's essay +``Unifying types and classes in Python 2.2'', I thought ``Wow, +classes of classes, cool concept, but how useful is it? +Are metaclasses really providing some new functionality? +What can I do with metaclasses that I cannot do without?'' + +Clearly, in these terms, the question is rather retorical, since in principle +any Turing-complete programming languages contains all the features provided +by metaclasses. Python metaclasses themselves are implemented in C, that has +no metaclasses. Therefore, my real question was not ``What can I do +with metaclasses that I cannot do without?'' but ``How big is the convenience +provided by metaclasses, with respect to my typical applications?''. + +The answer depends on the kind of problem you are considering. For certain +classes of problems it can be \emph{very} large, as I will show in this and in +the next chapters. + +I think the biggest advantage of metaclasses is \emph{elegance}. Altough it +is true that most of what you can do with metaclasses, can be done without +metaclasses, not using metaclasses can result in a much \emph{uglier} solution. + +One needs difficult problems in order to appreciate the advantage +of powerful methods. + +If all you need is to write few scripts for copying two or three files, +there is no point in learning OOP.On the other hand, if you only +write simple programs where you define only one of two classes, there +is no point in using metaclasses. Metaclasses becomes relevant only +when you have many classes, whole classes of classes with similar +features that you want to modify. + +In this sense, metaprogramming is for experts only, i.e. with people +with difficult problems. The point however, is that nowaydays, +many persons have difficult problems. + +Finally, let me conclude this preface by recalling the +gist of Python wisdom. +\begin{quote} +\begin{verbatim}>>> import this +The Zen of Python, by Tim Peters +. +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!\end{verbatim} +\end{quote} + +\end{document} + |