Jason in a Nutshell

Jason in a Nutshell

Jason Baker  //  Just another random geek. Visit my homepage at http://jason-baker.com

Follow me on twitter: http://twitter.com/jasonsupdates

Filed under

python

See all posts on posterous with this tag ยป
Dec 12 / 3:01pm

Syntax vs semantics: what's the difference?

This is a subject that many programmers get confused about.  The difference isn't really a difficult concept, it's just that it's not explained to programmers very frequently.  Let's consider a snippet of a poem by Jeff Harrison:

know-bodies, devoted we to under-do for you
every Sunday-day of dressy morning, black pond,
sky's germs, chairs' ponds - prove it, stain!
us, rain-free & orphaned, we're living laboratories

This is from Dart Mummy & The Squashed Sphinx.  If you haven't figured it out, this text is generated by a computer.  And it uses the same techniques that a lot of spammers use.  What's most interesting about this is that it's grammatically correct.  For instance, "prove it, stain!" is a perfectly valid English sentence.  The problem is just that it's meaningless.  Thus, we can say that the above poem is syntactically correct but has no meaning semantically.

Programming languages are similar in concept.  Consider the following Python snippet:

The above code is obviously incorrect.  It uses variables that haven't been declared yet.  Therefore, it is semantically incorrect.  But it is a syntactically valid Python program.

In the same manner, we can say that these two snippets of code are identical semantically although they definitely have very different syntax:

python

ocaml

Therefore, we can define these terms like this:

 * syntax - A set of rules for specifying a program
 * semantics - The meaning behind that program

 

Loading mentions Retweet
Filed under  //  ocaml   programming languages   python   semantics   syntax  

Comments (0)

Nov 3 / 1:41pm

7 tools for working with Python in Emacs (and Ubuntu)

I've been meaning to blog about this for some time, so I suppose now
is as good an opportunity as any. This is going to be a very "stream
of consciousness"-esque posting, so bear with me. Some of these are
things that have radically changed the way I use emacs. Others are
minor changes that I like. Feel free to pick and choose from them.

I'll assume you're running Ubuntu. Also, not all of these are Python
specific. But I feel that they will be useful to most Python
programmers who use emacs.

I should also note that (like most emacs users), most of these things
are tricks that I've picked up from various sources along the way. If
you wrote something that I put in here, thanks!

Ropemacs

Ropemacs is among the tools I love the most and hate the most. When
it works, it opens up a new world of automated refactorings for you.
But it seems to be a bit buggy at times. That said, setting it up is
really easy. Firstly, you need to have ropemacs installed. This is
pretty easy: 

 
sudo apt-get install python-ropemacs

After that, just a couple of lines of elisp in your .emacs file and
you're good to go! 

 
(require 'pymacs) 
(pymacs-load "ropemacs" "rope-") 
(setq ropemacs-enable-autoimport t)

Anything

Anything is almost like Quicksilver for emacs. To begin, you need to
download anything.el and anything-config. I also use 
anything-match-plugin. Then you just need the following lines of elisp: 

 
(require 'anything-config) 
(require 'anything-match-plugin) 
(global-set-key "\C-ca" 'anything) 
(global-set-key "\C-ce" 'anything-for-files)

Then, prepare to spend a lot less time searching for files!

Line number mode

When you're pair programming, nothing is more helpful than being able
to direct people to a certain line of code. This lets you spend less
time saying "hey, see that over there? It's about 3 lines up. No,
too far! go down another two lines." Installing this is really easy.
You just need linum.el and two lines of elisp: 

 
(require 'linum) 
(global-linum-mode 1)

Flymake through pyflakes

In case you miss the automatic error highlighting of the Visual Studio
world, you should realize that emacs has a similar system built-in.
It's called flymake. And you can make it work with Python as well. I
personally prefer to use pyflakes for this. All that's needed is
pyflakes: 

 
sudo apt-get install pyflakes

...and some elisp: 

 
(when (load "flymake" t) 
 (defun flymake-pyflakes-init () 
 (let* ((temp-file (flymake-init-create-temp-buffer-copy 
 'flymake-create-temp-inplace)) 
 (local-file (file-relative-name 
 temp-file 
 (file-name-directory buffer-file-name)))) 
 (list "pyflakes" (list local-file)))) 
 
 (add-to-list 'flymake-allowed-file-name-masks 
 '("\\.py\\'" flymake-pyflakes-init)))

Uniquify

How many __init__.py buffers do you have open at this moment? If
you're using emacs for Python programming, probably a lot. This is
where emacs's uniquify functionality is useful. It gives you a more
useful name for your buffers other than just appending a number at the
end. I have mine use the reverse of the directory. For instance, if
I have foo/__init__.py and bar/__init__.py open, they will be named
__init__.py/foo and __init__.py/bar respectively.

You just need this in your .emacs: 

 
(setq uniquify-buffer-name-style 'reverse) 
(setq uniquify-separator "/") 
(setq uniquify-after-kill-buffer-p t) ; rename after killing uniquified 
 
(setq uniquify-ignore-buffers-re "^\\*") ; don't muck with special 
buffers (or Gnus mail buffers)

python-mode

To be totally honest with you, I haven't used the built-in emacs mode
for python. I just installed python-mode because I was told it was
better. What I can tell you is that there is an occasional plugin
that requires python-mode. Installing it is easy. Just install
python-mode: 

 
sudo apt-get install python-mode

And add some elisp: 

 
(autoload 'python-mode "python-mode" "Python Mode." t) 
(add-to-list 'auto-mode-alist '("\\.py\\'" . python-mode)) 
(add-to-list 'interpreter-mode-alist '("python" . python-mode))

Pylookup

Pylookup is useful for those moments when you find yourself asking
something like "Is join in os or os.path?" Unfortunately, the setup
can be complex, but well worth it. There are instructions here.

     
Click here to download:
7_tools_for_working_with_Pytho.zip (49 KB)

Loading mentions Retweet
Filed under  //  emacs   python   ubuntu  

Comments (3)

Oct 29 / 6:42pm

The devil's in the details

There are two schools of thought in the programming world:

  1. Explicit is better than implicit (configuration over convention)
  2. A developer should only have to program the unconventional aspects of a program (convention over configuration).

We'll call #1 the Python school and #2 the Ruby school. In fact, I
would argue that this is an issue that's at the core of whether code
is considered "Pythonic" or "Rubyic" (I doubt the last one is a word).

So which school of thought is right? I personally think they both
are. It doesn't really take a whole lot to demonstrate that the
Python school of thought isn't always right. Think about it. Did you
know that the Python runtime has a component that goes around deleting
objects from memory totally implicitly? How unpythonic is that?

The Ruby school of thought takes a bit more work though. After all,
if it's unconventional, why should you have to configure it? Of
course, the problem here is in defining "conventional". What's
conventional to me is likely unconventional to others. And what's
conventional to others could be unconventional to me.

I wish I had more advice on how to reconcile these two schools of
thought. The truth is that I struggle with them daily. But I think
having an intuition about this is the dividing line between
"experienced programmer" and "newb". After all, if programming were
merely about "make everything explicit" or "make everything implicit",
any idiot could do it.

I think this is also the core skill for writing readable code. You
need to determine what details are relevant to each piece of code.
Whatever the case, you need to make a conscious decision as to what
details shine through and what details you obscure. Because if these
things happen on accident, they're almost guaranteed to be wrong.

Loading mentions Retweet
Filed under  //  programming   python   ruby  

Comments (1)

Oct 15 / 5:14pm

Persistence is a subset of immutability

Whenever I tell someone I'm working on a persistent data structure 
library for Python, I almost always get the same response: 
"Persistent means that something is stored across process boundaries. 
I think you mean to say immutable data structures."  In fairness, this 
response is understandable.  But it's not quite right.  I'm going to 
address both of the points in the above statement. 


Persistent means that something is stored across process boundaries


Did you that letter can mean a note you send through the mail or a thing you use to make up words?  Did you know that programming can mean writing computer programs or mathematical optimization?  I'm sure if I sat down long enough, I could think of more examples.  The point is that the language we speak is full of ambiguities and whatnot. 

Before we consider the computer science meaning of persistence, let's 
look at the common meaning.  If we look at the word persistent in 
Merriam-Webster, the first two definitions we run into are: 

1 : existing for a long or longer than usual time or continuously: as 
a : retained beyond the usual period  b : continuing without change in 
function or structure 

The meaning Python programmers tend to think of is the definition in 
part a.  That is, a persistent data structure is stored beyond the 
usual period (the process's lifespan).  However, when I talk about a 
persistent data structure, I tend to mean the definition in part b. 

Going with definition b, we can see that lists for example aren't persistent: 

 
>>> a = [1,2,3] 
>>> b = a 
>>> b.append(4) 
>>> a 
[1, 2, 3, 4] 
 

Tuples, however, are a different matter: 

 
>>> a = (1,2,3) 
>>> b = a + (4,) 
>>> b 
(1, 2, 3, 4) 
>>> a 
(1, 2, 3) 
 

Ah, but here's where the second part of this post comes in.

I think you mean to say immutable data structures

In the case of the tuple, you are correct to say that a tuple is 
immutable.  And I'm correct in saying that a tuple is persistent. 
Just like I'd be right to say that I own a car while someone else 
claims that I own an automobile.  However in both cases, they can't 
quite be used interchangeably.  After all, an automobile isn't 
necessarily a car.  It can be a truck or a van or an SUV. 

In the same sense, a persistent data structure is effectively 
immutable.  But an immutable data structure isn't necessarily 
persistent.  Let's consider the definition of both of these words from 
wikipedia: 

Immutable object


In object-oriented and functional programming, an immutable object is 

an object whose state cannot be modified after it is created. 


Persistent data structure


In computing, a persistent data structure is a data structure which 

always preserves the previous version of itself when it is modified; 

such data structures are effectively immutable, as their operations

do not (visibly) update the structure in-place, but instead always

yield a new updated structure. 


These definitions have a lot of common ground, but there is some 
difference between them.  Let's consider a data structure that is 
immutable but not persistent.  Prepare yourself.  This will be 
complex.  Ready? 

 
>>> 1 
1 
 

Has your mind been blown yet? 

In this sense, the number 1 is definitely immutable.  You can't change 
it.  It's always the number 1.  However, it's not persistent.  How do 
you update the number 1?  No matter what you do, it will always be the 
number 1.  Sure, you can get 3 by adding it to 2.  But in a 
mathematical sense, that's not really changing the number 1. 

In this sense, the number 1 is atomic.  It simply doesn't make sense 
to modify it.  Heck, you can't even copy it: 

 
>>> from copy import copy 
>>> a = 1 
>>> a is copy(a) 
True 

Conclusion

With this semantic difference in mind, remember that it's just that: 
a semantic difference.  Call them Bob if you want to.  However, bear 
in mind that when someone uses the word persistence in this way, 
they're not being inaccurate.

 

Loading mentions Retweet
Filed under  //  functional-programming   persistence   programming   python  

Comments (0)