>> >> (3) Add macros. We still have to figure out how to limit their
obfuscation.
>> > nobody has given even a *remotely*
>> > plausible mechanism for how exactly you would get code executed at
>> > compile time.
>> macros can (and *possibly* should) be evaluated at run-time.
> We must still have very different views on what a macro is.
In a compiled language, it is (necessarily) compiled. In an interpreted
language, it doesn't have to be.
> After a macros is run, there is new syntax that needs to be parsed
> and compiled to bytecode. ... anything that requires invoking the
> compiler each time a macro is used will be so slow that nobody will
> want to use it.
I had been thinking that the typical use would be during function (or
class) definition. The overhead would be similar to that of decorators,
and confined mostly to module loading.
I do see your point that putting a macro call inside a function could be
slow -- but I'm not sure that is a reason to forbid it.
>> Even if the macros just rerun the same boilerplate code less efficiently,
>> it is still good to have that boilerplate defined once, instead of cutting
>> and pasting. Or, at least, it is better *if* that once doesn't become
>> unreadable in the process.
> I am unable to assess the value of this mechanism unless you make a
> concrete proposal. You seem to have something in mind but you're not
> doing a good job getting it into mine...
I'm not confident that macros are even a good idea; I just don't want
a series of half-macros. That said, here is a strawman.
defmacro boiler1(name, rejects):
def %(name) (*args):
for a in args:
if a in %(rejects):
print "Don't send me %s" % a
...
boiler1(novowels, "aeiouy")
boiler2(nokey5, "jkl")
I'm pretty sure that a real version should accept suites instead of just
arguments, and the variable portion might even be limited to suites
(as in the thunk discussion). It might even be reasonable to mark
macro calls as different from function calls.
template novowels from boiler1("aeiou"):
<suite>
but I can't help thinking that multiple suites should be possible, and
then they should be named, and ... that spurred at least one
objection. http://mail.python.org/pipermail/python-dev/2005-April/052949.html
-jJ
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
