Markdown has very little to do with python testing.
But I need a project to test, so I’m writing my own Markdown script.
This is a brief introduction to Markdown from my perspective.

Writing HTML sucks. Use Markdown.

HTML is obviously pretty helpful and critical for the web.
One goal for HTML was that humans could reasonably easily read, write, and edit it.
And that kinda works. Sometimes.
But it’s not fun to read or write HTML. Actually, writing stuff in HTML by hand sucks.

That’s the conclusion that lots of people have come to, including John Gruber, (and me).

So what do we do about it?

One of the solutions to the problem is to create an intermediate language that is easy to write for humans, and easy to convert to HTML.

That’s what Markdown is. It’s an intermediate language. John Gruber wrote the original Markdown Syntax, and a perl script to convert that syntax into HTML.

If I want a grocery list:

  • eggs
  • milk
  • cheese

I used to have to write:

<ul>
<li> eggs </li> 
<li> milk </li> 
<li> cheese </li> 
</ul> 

But now with markdown, I just need to write:

* eggs 
* milk 
* cheese 

And then I send this through the handy perl script to convert it. That already is way better, and it’s easy to read as is.

I want to write my own converter.

So I could just use markdown.pl, or one of the many implementations in other languages.

But I’m pretty picky. I’m probably going to want to drop some of the syntax. And as far as Python versions, I can’t find a single file implementation. I did like that aspect of the original Perl version.

These are some of the reasons I liked the original markdown.pl script:

  1. It is only one file. It’s just one perl script file. Nothing extra to install. No extra libraries needed.
  2. It can convert a file, if you pass it a file name.
  3. It also accepts markdown text from the standard input stream, so you can pipe to it.
  4. It just simply works without a lot of fuss.

However, there are already a bunch of other Markdown converters, so why on earth am I writing one?

  1. I need a project to use on this site as a demonstration project. Something to demonstrate testing strategy, and to some degree, software development strategy.
  2. Markdown is a well-defined, known problem.
  3. I am used to regular expressions in perl, but not so much in python. Markdown is a good problem space to learn about regular expressions.
  4. I’d like to have a markdwon implementation I control, so I can extend it any way I feel like. Selfish, yes, but true.

Before I start writing my own version, I think I should:

  • define the requirements for my new markdown script
  • jot down my testing strategy
  • get some revision control in place

Then, you know, I ought to start writing the darn thing.

I know. The classic blunders are:

  1. Never get involved in a land war in Asia
  2. Never go in against a Sicilian when death is on the line.
  3. Never try to parse HTML with regular expressions.

And since full Markdown is a superset of HTML, it follows that you shouldn’t try to parse markdown with regular expressions.

However, I’m planning on implementing a subset of markdown, which will not include parsing embedded html. At least, that’s my plan.