mtomassoli

I do research for the heck of it and if other people think that what I'm doing is useless, I'm ok with that. That's the mathematician way. The exploration is the end, not the mean.

I'm not trying to convince anyone that my "project" is useful because that's not my project anymore. Anyone can look at it, dissect it, propose new feature, etc... Now that the thrill of the exploration is almost over, I'm losing interest... but I'll keep an eye on my repository on bitbucket.

By the way, if someone could provide better examples, documentation, etc... I'd be grateful. Let's just say I'm not much into the "convincing thing". If you need convincing, don't look at me. I gave you an object. Now it's your job to figure out what to do with it (or just toss it away) ;)

People want...? codeblocks is free and I don't get paid for it. If someone is so lazy that he won't even have a look at the doc in the code (as suggested in my article), I don't want to have anything to do with him or her.

1 click --> bitbucket

1 click --> source

1 click --> codeblocks.py

It's that too much to ask?

No string literals are evaluated as code. Everything is rewritten and then evaluated and executed at full speed.

I don't believe it. Let's try to fix it again... thanks.

I think that "readability" also depends on what you're used to reading and writing. To me, my code blocks are quite readable, but that's only true because I've seen a lot of them in these last two weeks.

Code blocks let you write

  with myfunc(iter) << 'x, y':
    code which uses x and y

instead of

  def some_func_name(x, y):
    code which uses x and y
  myfunc(iter, some_func_name)

If you prefer the second form, then you don't need code blocks. I think the first form is much better. It's not just a matter of saving one single line: you don't have to define a function which you'll never use again, so the first code is actually more readable.

By the way, I wish that '<' was a simple typo. Unfortunately it's Wordpress: it's driving me mad. Everytime some code has '<' and '>' in it, something unexpected happens.

Just read the docstring of the module. It's very detailed.

As for mixing strings with code, I still need to adhere to Python's syntax in order to avoid syntax errors. Anyway, syntax errors in strings are caught at "rewriting time". Using words instead of operators would also cause some problems.

Oh, I know. My module is your fault! :)