the two books i like better (theyre also available online for free from the author-- you want paper youve still gotta give them money)
are lpthw, and the extremely friendly "think python" from allen downey.
i recommend the first edition, because python 2 is closer to basic.
* pdf: http://greenteapress.com/thinkpython/thinkpython.pdf
* html: http://greenteapress.com/thinkpython/html/index.html
unlike "think python," i never used lpthw to learn python. but ive paged through it, and it should be useful, too-- it has a great reputation as a first python book:
* html (free): https://learnpythonthehardway.org/book/
(table of contents)
* pdf is $29.99 and comes with some extras: https://shop.learncodethehardway.org/access/buy/2/
not trying to sell zed shaws book here, just trying to save you the search for the pdf. if walt wants to remove the commercial link, thats alright. if he wants to leave it here, thats great too. its not like im against zed shaw making money-- the pdf has no drm, or i wouldnt link to it even if you asked me.
i wrote a book on fig that includes this chapter about python, i dont know if it will help to post it here or not:
Chapter 8: A little Python
As far as coding goes, you can write pretty much anything in fig you
want to. It may not be the fastest language, or have a feature for
everything, but you can extend it using Python.
Python is a great second language to learn, and is still probably
If you have no interest in Python yet, you don't actually need this
chapter. Think of it as "extra credit,” but definitely don't worry if
Python seems too complicated.
A few months of coding in any language should make learning Python
easier, and there are better intros to the language than this one;
this one is just made for people comfortable with fig.
If this chapter only started with what makes Python different than
fig, you might think Python is either pure genius (it basically is) or
that it makes things more difficult than necessary (it sometimes
It should be noted that Python is a little closer to what you should
expect from most languages than fig is. Fig was designed specifically
to round off (some might even say cut) as many corners as
possible. Today, most languages are case-sensitive, Python has to be
indented just so, and while fig has a "main variable” at the beginning
of most lines, Python requires that you at least set every variable to
something before you can reference it.
Fig COULD automatically return 0 for any variable referenced, even if
not used already. Since most modern languages don't do this (and even
have a good argument against it) Fig uses its main variable concept
instead, which has the following features:
* It makes it obvious what variables are used in a program
* It zeroes unused variables in a way that is less work than Python,
but relatively compatible with most modern languages-- it is
minimalist yet still explicit.
* It works like a "named pipe,” (a concept in Unix-like operating
systems) where a number of built-in functions can reference and
change the contents of a stream of data implicitly:
x arropen "file.txt" | join x " " | ucase | print
works kind of like this command in GNU/Linux:
x=$(cat file.txt | sed 's/\n/\ /g' | tr a-z A-Z) ; echo $x
The pipes: | in fig don't change the way that fig works, they are
simply a substitute command separator for Python's ";" or Basic's ":".
Fig is therefore also a simple (sort of) introduction to coding in
Bash. Although it barely is the case, the main variable functionality
does transition a little to using pipes in Bash.
But getting back to Python, you must name (and set) a variable before
you can reference (or use) it:
x = 0 ; print(x) # Python uses hashes for comments
because fig allows a certain amount of decorative punctuation, this
will work in fig:
x = 0 ; print # fig uses hashes for comments too
but the x after print is implied. In Python, the semicolon ; between
commands and the equals = between variable name and value are
required. And of course, every function, like print(), requires the
variable to be named.
x = 0 ; print (x) ; print (x) # Python
x 0 print print # fig
another thing worth mentioning about Python is that it comes in two
major versions: 2 and 3, which are both still in use. A lot of
professionals still prefer Python 2, as do I; fig was conceived as a
Python 2 project, and I would love to make fig a project for Python 2
in the long run.
Fig from version 3.0 onward runs in Python 3. More about this
In some ways, Python 2 is more friendly and flexible. The biggest
difference is string handling, and the print command. In Python 2,
print works like this:
print x, y, z
In Python 3, print works like this:
print(x, end=' ')
print(x, y, z)
Ok, so what's the big deal then? Well it doesn't stop there, if you
want to save or load a file, or print certain characters, or read
from stdin-- all stuff Python 2 makes trivial that's more of a hassle
in Python 3.
Fig would still be a Python 2 project, except the Python Foundation
was supposed to drop support for it in 2015, and has only extended it
to 2020. I still hope that the many people who prefer 2 will fork the
language, perhaps calling it "boa" or something.
At that point, I would most likely change fig back to Python 2
(because transitioning is a feature, and I think 2 is better for
education.) But in the meantime, fig 3.0 onward is a Python 3 project.
If someone is interested enough in Python 2.9 (or earlier) to fork or
maintain it, they should feel (they are) free to do so; I would
Fig was made with the hopes that more people would understand and even
write programming languages, and a programming language made from (any
version of) fig would be a very cool thing to find.
I'm focused on Python 3** reluctantly-- because it may really be the
version of Python we are all stuck with sooner or later. It's too bad.
** [Note: I've switched back to Python 2 since writing this.]
Anyway, a fig program that works in 2.9 will probably work the same
in fig 3.x, but eventually fig may have features (command is one)
that aren't available in 2.9.
As for inline Python, the version of fig (2 vs. 3) is also the version
of Python you must use. So fig 3.1 requires inline Python 3 syntax.
One of the largest differences between fig and Python is indentation.
A lot of my fig examples I indent "Python-style" but in Python, you
must indent each block of code: and you must unindent at the end of it.
So this for loop in fig:
for x (1 10 2)
now x print
corresponds to the following loop in Python:
for x in range(1, 10 + 1, 2):
now = x ; print(now)
There's no "next" in Python; the change in indentation is how it
Nested loops in fig and Python:
for y (1 5 1)
for x (1 10 2)
now x prints " " prints
now y print
for y in range(1, 5 + 1, 1):
for x in range(1, 10 + 1, 2):
now = x ; print(now, end=' ')
now = y ; print(now)
In Python, some functions are built in (like int() and print() and
join() for example) while others have to be imported:
x 3.14 cos print # fig
from math import cos ; print cos(3.14) # Python
Just like defining a function, you only have to import cos once per
program to use it as many times as you like. Another way to do the
import math ; print math.cos(3.14)
The advantage of doing it that way is that it imports the entire math
library at once, so you don't have to keep importing each of its
from sys import stdin
for p in stdin: ps += [p[:-1]]
This is where fig's arrstdin comes from.
Fig's function is named for the Basic command, but:
def replace(phrase, chfrom, chto):
phrase = phrase.split(chfrom)
in Python, function is called def.
Note also that join x y becomes y.join(x) and split x y becomes
x.split(y) ...in python you can just do this, which is easier:
phrase = phrase.replace(x, y)
Block commands aside, most functions in fig start with
def figcommandname in fig's Python source. So in the fig translator
def figint(p): return int(p)
is the code in Python that performs int in fig. Sometimes the
translation is that simple, and sometimes it isn't. From inline
Python in fig:
figcolortext(0, 1) ; fighighlight(0, 7)
# fig's int function:
print(figint(x) * 10)
So not only can you use inline Python, you can use fig functions (some
of them) inside inline Python. When all of it is inline Python, you
can copy the fig functions and use them in a pure Python script.
License: Creative Commons CC0 1.0 (Public Domain)