Comments on Just a little Python: Python Macros?

I want to replace for with a parallel_for that doe...

2010-07-01T08:20:24.920-04:00

I want to replace for with a parallel_for that does something else with the block underneath the for. In order to do that with "with" I need to bracket the "for" with "withs"

with parallel_sync():
for i in range(0,4):
with parallel_split():
...closure that will have each
instance of the "for" run in
...parallel

This is the only way I can know,
1)each time I enter and leave an individual loop of the for block
2)when I leave the entire for block

decent for macro'ed with a while

2010-04-17T17:15:53.444-04:00

decent for macro'ed with a while

http://www.cs.brown.edu/~sk/Publications/Talks/Swi...

2010-03-13T17:36:17.998-05:00

http://www.cs.brown.edu/~sk/Publications/Talks/SwineBeforePerl/

Watch the presentation and the slides about implementing a Finite Automata using Scheme Macros.

@jeremy: The way this is typically done in python...

2009-11-18T09:50:50.911-05:00

@jeremy:

The way this is typically done in python is to write an assertion function (this is how the unittest module does it):

assert_raises(ExceptionType, func, *args, **kwargs)

where the assert_raises function is something like:

def assert_raises(t, func, *args, **kwargs):
  try:
    func(*args, **kwargs)
    assert False, '%s not raised' % t
  except t:
    return
  except:
    raise

But I can definitely see how macros could be useful, as well.

I'm just starting Python, and I already found ...

2009-11-17T23:57:13.523-05:00

I'm just starting Python, and I already found a good use case for Macros.

I want to run a test which is expected to raise an exception and write it like this:

test-exn("exception content", func(args));

Namely, I want this to expand to a try/catch statement without having to write the try/catch, and without having to write a class to encapsulate unit tests. These are for small scripts, but they're large enough that I want to have a small bit of regression testing. Perhaps I'm writing a miniature interpreter...

Lisp macros can (and do) do this.

...and now I see MetaPython... nice work! Don...

2009-11-07T18:16:37.322-05:00

...and now I see MetaPython... nice work! Don't know if it's enough to keep me in Python-land for the long-term, but definitely cool.

The point of macros is that you can extend the lan...

2009-11-06T18:23:58.251-05:00

The point of macros is that you can extend the language without cooperation from the core developers. Consider the new Python "with" statement. If Python had macros, not only could this have been implemented outside the core (rather than waiting for a committee to debate it for months), it could easily be backported to older versions of Python.

Python has such a rich array of features precisely because it must. Since it's impossible to extend the language in any significant sense, it must implement every useful feature it can. Some of us think of this as "bloat".

@Scott: I suppose I can see using macros to differ...

2009-03-16T16:55:00.000-04:00

@Scott: I suppose I can see using macros to differentiate between debug and optimized code, although it looks like you have a passable workaround with simple Python conditionals. It seems that a macro facility would probably make your "massive code project" code look cleaner (i.e. without the conditionals).

Between that example and collections.namedtuple, I'm just about convinced that macros could add something to Python. After reading the comments here, however, I am also convinced that Python needs them a lot less than a minimalist language like Lisp.

Macros are great for conditionally ignoring a sect...

2009-03-16T09:55:00.000-04:00

Macros are great for conditionally ignoring a section of code. The one particular use I have in mind is for debug logging. Our massive code project is littered with function calls to do debugging, protected by `if trace_level` conditionals to prevent evaluation of the function call and its (sometimes obscenely large) argument payload. Two of the most expensive things one can do in Python are create objects and call functions, and logging generally does both.

Rick, it was good seeing you last night. I think P...

2009-03-13T22:00:00.000-04:00

Rick, it was good seeing you last night. I think Python and Lisp are pretty close in terms of expressiveness. They have different philosophies though, and it attributes to why/how they are different. I much prefer Python's syntax to Lisp - code is generally much more pleasant to read, which is a big win. On the other hand, I like the simplicity of Lisp, in that there's just not that much to it. Macro's are so powerful you can do almost anything with it. On the other hand in Python, you have a large set of tools at your disposal(metaclasses, decorators, generators, the *with* clause, etc.). There's more you need to learn and more to chose from. Also, since they are language features, you can't extend them yourself - we have to design them by committee. Python wasn't always this expressive - It took many years to get to this point. Lispers were already enjoying their Macros almost at the beginning. Back then, there was nothing close to it, so it's no wonder they are so enthusiastic about them. Things are a bit different now - other languages have caught up.

@Zellyn: I see what you're saying, and I agre...

2009-03-13T10:26:00.000-04:00

@Zellyn: I see what you're saying, and I agree that the type(...) approach can be off-putting, but I can also just write the following:

class Test(BrowserTestCase):
    browser = browser
Test.__name__ = 'Test%s' % browser

In Python 2.6, I could even write a class decorator to clean it up:

@setname('Test%s' % browser)
class Test(BrowserTestCase):
    browser = browser

where I have

def setname(name):
    def inner(o):
        o.__name__ = name
        return o
    return inner

Another thing I didn't like about the type(...) approach is that it doesn't account for metaclasses, but that's a minor pet peeve.

Actually, since you mentioned this, I can now think of a good use case for macros -- it would clean up the collections.namedtuple class generator quite a bit. Right now, it puts together a string and eval()s it. Kind of a poor man's macro anyway.

Macros allow your code-definition code to look mor...

2009-03-13T10:15:00.000-04:00

Macros allow your code-definition code to look more like regular code.

The type() example from last night's PyATL meetup is a good example:

class Test{BROWSER}(BrowserTestCase):
browser = {BROWSER}

looks a lot more like a normal Python class definition than:

type("Test%s" %(CLASSNAME, BROWSER), (BrowserTestCase,), dict(browser=BROWSER))

I guess Lisp programmers when creating templating ...

2009-03-12T15:17:00.000-04:00

I guess Lisp programmers when creating templating or configuration languages want to keep programming in Lisp plus a few additions, whereas Python programmers either need something completely different so that a few macros would not help them much anyway or if they want Python they want to stay as close as possible to its syntax.

Yeah, I suppose you could -- I like the idea of a ...

2009-03-12T14:51:00.000-04:00

Yeah, I suppose you could -- I like the idea of a context manager approach -- in fact, I'll probably implement it that way sometime next week now that you point it out.

I think the original point probably still stands though -- any where you have a set of boiler-plate code, it may be nice to have macro support.

That said, as you've pointed out, it's nowhere near as important as in less flexible languages like C++!

@chphilli: I kind of see what you're saying, b...

2009-03-12T13:57:00.000-04:00

@chphilli: I kind of see what you're saying, but couldn't you achieve the same thing with either a decorator (to guard a function) or a context manager (to guard an arbitrary block of code)?

with logging_exceptions:
    some
    potentially
    exception
    raising
    stuff

A coworker and I were just discussing this the oth...

2009-03-12T12:37:00.000-04:00

A coworker and I were just discussing this the other day...

In C++ development at my previous employment, we used macros all the time, to reduce repeated code patterns. The most common example was in exception handling, for example, catching, logging, and then re-throwing an exception.

As I was writing "except Exception, e: ..." for yet another time the other day, I realized that with macros I could have avoided this repetition. Avoiding repetition means I only have to write it once, and thus, less potential for bugs!

@anonymous: Not that I think it's a good idea, bu...

2009-03-12T11:45:00.000-04:00

@anonymous: Not that I think it's a good idea, but you can actually do that without macros using metaclasses.

Macros could allow you to not use explicit self in...

2009-03-12T11:41:00.000-04:00

Macros could allow you to not use explicit self in every class method...

I'm learning PLT Scheme right now and while the ID...

2009-03-12T11:21:00.000-04:00

I'm learning PLT Scheme right now and while the IDE is quite cool, I don't see much point to macros either.

I think macros could create idiosyncratic constructs, which not pythonic.