Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Python #ifdef

2,483 views
Skip to first unread message

Carlos Nepomuceno

unread,
May 28, 2013, 3:46:37 PM5/28/13
to pytho...@python.org
Are there Python 'preprocessor directives'?

I'd like to have something like '#ifdef' to mix code from Python 2 and 3 in a single file.

Is that possible? How?

Joel Goldstick

unread,
May 28, 2013, 3:49:03 PM5/28/13
to Carlos Nepomuceno, pytho...@python.org

Dave Angel

unread,
May 28, 2013, 3:57:49 PM5/28/13
to pytho...@python.org
On 05/28/2013 03:46 PM, Carlos Nepomuceno wrote:
> Are there Python 'preprocessor directives'?

Python doesn't define a preprocessor, and CPYthon doesn't implement one.
Nothing to stop you from doing so, however.
>
> I'd like to have something like '#ifdef' to mix code from Python 2 and 3 in a single file.
>
> Is that possible? How?
>

It's quite possible that you don't need a preprocessor do what you want,
since Python does much less compile-time checking than C. Also, it's
possible to store function objects and module objects in variables, and
thus to hide many things from the body of the code.

One biggie is print, since that's a reserved word (and a statement) in
Python 2.x. But if you're using 2.7 you can use from __future__ import
print, or something like that, and just use 3.x function semantics.


--
DaveA

Neil Cerutti

unread,
May 28, 2013, 4:00:04 PM5/28/13
to
On 2013-05-28, Joel Goldstick <joel.go...@gmail.com> wrote:
>
> No

Yes. More below.

> On May 28, 2013 3:48 PM, "Carlos Nepomuceno" <carlosne...@outlook.com>
> wrote:
>> Are there Python 'preprocessor directives'?
>>
>> I'd like to have something like '#ifdef' to mix code from Python 2 and 3
>> in a single file.
>>
>> Is that possible? How?

You need sys.version_info.

For more, see http://python3porting.com/noconv.html

--
Neil Cerutti

Carlos Nepomuceno

unread,
May 28, 2013, 4:07:39 PM5/28/13
to pytho...@python.org
Thank you! I made it run like the following. What do you think about that? IS there a better way?

#The following runs on Python 2.7
sc3='''
# Python 3
def original(n):
    m = 0
    for b in n.to_bytes(6, 'big'):
        m = 256*m + b
    return m
'''
if sys.version_info[0] == 3:
    exec(sc3)

Grant Edwards

unread,
May 28, 2013, 4:12:59 PM5/28/13
to
On 2013-05-28, Carlos Nepomuceno <carlosne...@outlook.com> wrote:

> Thank you! I made it run like the following. What do you think about
> that? IS there a better way?
>
> #The following runs on Python 2.7
> sc3='''
> # Python 3
> def original(n):
> ??? m = 0
> ??? for b in n.to_bytes(6, 'big'):
> ??????? m = 256*m + b
> ??? return m
> '''
> if sys.version_info[0] == 3:
> ??? exec(sc3)

You're trying to make this a lot harder than it really is:

if sys.version_info[0] == 3:
def original(n):
m = 0
for b in n.to_bytes(6, 'big'):
m = 256*m + b
return m
else:
def original(n):
<something else?>


--
Grant Edwards grant.b.edwards Yow! Am I having fun yet?
at
gmail.com

Benjamin Kaplan

unread,
May 28, 2013, 4:14:57 PM5/28/13
to Python List


On May 28, 2013 1:10 PM, "Carlos Nepomuceno" <carlosne...@outlook.com> wrote:
>
> Thank you! I made it run like the following. What do you think about that? IS there a better way?
>
>
>
> #The following runs on Python 2.7
> sc3='''
> # Python 3
> def original(n):

>     m = 0
>     for b in n.to_bytes(6, 'big'):
>         m = 256*m + b
>     return m

> '''


> if sys.version_info[0] == 3:

>     exec(sc3)
> --

No need for exec.

if sys.version_info[0] >= 3:
    def original(n) :
       ...

Carlos Nepomuceno

unread,
May 28, 2013, 4:22:40 PM5/28/13
to pytho...@python.org
----------------------------------------
> From: inv...@invalid.invalid
> Subject: Re: Python #ifdef
[...]

> You're trying to make this a lot harder than it really is:
>
> if sys.version_info[0] == 3:
> def original(n):
> m = 0
> for b in n.to_bytes(6, 'big'):
> m = 256*m + b
> return m
> else:
> def original(n):
> <something else?>
>
>
> --
> Grant Edwards grant.b.edwards Yow! Am I having fun yet?
> at
> gmail.com

Haha! That's it!!!

Just realized how funny this can be: ;)

### never to be opened ###
def pandoras_box(v):
    return v/0.0

if customer_didnt_pay():
    pandoras_box()

#lol

Fábio Santos

unread,
May 28, 2013, 4:34:36 PM5/28/13
to Carlos Nepomuceno, pytho...@python.org


On 28 May 2013 21:26, "Carlos Nepomuceno" <carlosne...@outlook.com> wrote:
> Haha! That's it!!!
>
> Just realized how funny this can be: ;)
>
> ### never to be opened ###
> def pandoras_box(v):
>     return v/0.0
>
> if customer_didnt_pay():
>     pandoras_box()
>
> #lol

1/0 is, after print, my most common debug statement.

Grant Edwards

unread,
May 28, 2013, 4:42:34 PM5/28/13
to
On 2013-05-28, Carlos Nepomuceno <carlosne...@outlook.com> wrote:

> [...]
>> You're trying to make this a lot harder than it really is:
>>
>> if sys.version_info[0] == 3:
>> def original(n):
>> m = 0
>> for b in n.to_bytes(6, 'big'):
>> m = 256*m + b
>> return m
>> else:
>> def original(n):
>> <something else?>
>
> Haha! That's it!!!
>
> Just realized how funny this can be: ;)

Here's the important lesson from this thread:

Instead of asking "how do I write X in Python" where yoy've assumed X
is the solution to your problem, you're usually better off asking how
to solve the underlying problem in a Pythonic way.

IOW, instead of asking about a Python preprocessor (which you have
assumed is the solution to the problem because that's how you would do
it in C), ask about the actual problem (how to define a function
differently depending on Python version).

People on this list are very inventive and will expend a surprising
amount of time to figure out often too-clever ways to do X because you
asked how to do X -- even if doing X is a lousy way to solve your
actual problem...

When asking how do I solve a problem, it's OK to illustrate that
question with an example X of how you would solve it in C or Java or
Ruby or Perl or whatever, but remember

1) Not everybody here knows C or Java or Ruby or Perl or whatever,
and the person who _does_ know everyting there is to know about
solving some particular underlying problem isn't going to go
learn a new language so that they can understand your example and
figure out what you're trying to accomplish.

2) Programming languages differ. X may be the best way to solve the
problem in one language, but it might be an awful way to do it in
another language.

--
Grant Edwards grant.b.edwards Yow! I'm ANN LANDERS!!
at I can SHOPLIFT!!
gmail.com

Carlos Nepomuceno

unread,
May 28, 2013, 4:48:32 PM5/28/13
to pytho...@python.org
________________________________
> Date: Tue, 28 May 2013 21:34:36 +0100
> Subject: RE: Python #ifdef
> From: fabiosa...@gmail.com
> To: carlosne...@outlook.com
> CC: pytho...@python.org
>
>
> On 28 May 2013 21:26, "Carlos Nepomuceno"
> <carlosne...@outlook.com<mailto:carlosne...@outlook.com>>
> wrote:
> > Haha! That's it!!!
> >
> > Just realized how funny this can be: ;)
> >
> > ### never to be opened ###
> > def pandoras_box(v):
> > return v/0.0
> >
> > if customer_didnt_pay():
> > pandoras_box()
> >
> > #lol
>
> 1/0 is, after print, my most common debug statement.

What's the best debugger for Python? Have you tried HAP[1]?

[1] http://hapdebugger.sourceforge.net/

Carlos Nepomuceno

unread,
May 28, 2013, 4:54:46 PM5/28/13
to pytho...@python.org
----------------------------------------
> From: inv...@invalid.invalid
> Subject: Re: Python #ifdef
> Date: Tue, 28 May 2013 20:42:34 +0000
> To: pytho...@python.org
[...]


You're right! Sometimes I hate myself for doing exactly the opposite of what I would like to do!

Unfortunately I can't change the thread subject.

How do you have "inv...@invalid.invalid" instead of your email address?

Mark Lawrence

unread,
May 28, 2013, 6:18:34 PM5/28/13
to pytho...@python.org
On 28/05/2013 20:46, Carlos Nepomuceno wrote:
> Are there Python 'preprocessor directives'?
>
> I'd like to have something like '#ifdef' to mix code from Python 2 and 3 in a single file.
>
> Is that possible? How?
>

https://pypi.python.org/pypi/six/1.3.0

--
If you're using GoogleCrap™ please read this
http://wiki.python.org/moin/GoogleGroupsPython.

Mark Lawrence

Joel Goldstick

unread,
May 28, 2013, 6:25:59 PM5/28/13
to Mark Lawrence, pytho...@python.org
my original response was from cell phone.  I just answered that you can't do ifdefs, implying that there is no preprocessor in python.  I learned a lot of things I didn't know reading the thread, but I wonder if it is a good idea in general to try to write code like this.  -- combined 2.x/3.x codebase can be a bear to maintain.  I wouldn't do it unless there was some imposing reason that I must.  Its not just print() -- that isn't bad, but changes in module names (urllib), arithmetic, and unicode especially make this idea in general, very tricky.  Pity the next developer who needs to try to maintain it.

So, maybe you CAN do it, but SHOULD you want to do it?

--

Carlos Nepomuceno

unread,
May 28, 2013, 6:50:35 PM5/28/13
to pytho...@python.org
________________________________
> Date: Tue, 28 May 2013 18:25:59 -0400
> Subject: Re: Python #ifdef
> From: joel.go...@gmail.com
> To: bream...@yahoo.co.uk
> CC: pytho...@python.org
[...]

>
> my original response was from cell phone. I just answered that you
> can't do ifdefs, implying that there is no preprocessor in python. I
> learned a lot of things I didn't know reading the thread, but I wonder
> if it is a good idea in general to try to write code like this. --
> combined 2.x/3.x codebase can be a bear to maintain. I wouldn't do it
> unless there was some imposing reason that I must. Its not just
> print() -- that isn't bad, but changes in module names (urllib),
> arithmetic, and unicode especially make this idea in general, very
> tricky. Pity the next developer who needs to try to maintain it.
>
> So, maybe you CAN do it, but SHOULD you want to do it?
>
> --
> Joel Goldstick
> http://joelgoldstick.com


Thanks Joel! In this case I think it does because I would like to have the same short benchmarking script to be runnable by Python 2 and Python 3.

The only piece of code that doesn't run on Python 2 is a to_bytes() single call. So it's not a huge maintenance load. ;)

I didn't try to write 'portable' code to Python 3 yet. What's the catch?

Fábio Santos

unread,
May 28, 2013, 6:51:08 PM5/28/13
to Carlos Nepomuceno, pytho...@python.org


On 28 May 2013 21:53, "Carlos Nepomuceno" <carlosne...@outlook.com> wrote:
>
> ________________________________

Never saw that, but the remote debugging looks like it adds some flexibility. That said, I don't often use a debugger. When I do, it's pdb. Pdb is not bad at all, and it comes in the stdlib, which makes it readily available in a virtualenv. It's impractical to set more than a breakpoint, but then again I only use a breakpoint at a time.

88888 Dihedral

unread,
May 28, 2013, 7:04:25 PM5/28/13
to
Carlos Nepomuceno於 2013年5月29日星期三UTC+8上午3時46分37秒寫道:
> Are there Python 'preprocessor directives'?
>
> I'd like to have something like '#ifdef' to mix code from Python 2 and 3 in a single file.
>
> Is that possible? How?

Use execfile(filename) at the beginning to get what you want.
The .pyc version is preferred.

Terry Jan Reedy

unread,
May 28, 2013, 8:31:39 PM5/28/13
to pytho...@python.org
On 5/28/2013 6:25 PM, Joel Goldstick wrote:
> On Tue, May 28, 2013 at 6:18 PM, Mark Lawrence <bream...@yahoo.co.uk
> <mailto:bream...@yahoo.co.uk>> wrote:

> On 28/05/2013 20:46, Carlos Nepomuceno wrote:
> I'd like to have something like '#ifdef' to mix code from Python
> 2 and 3 in a single file.

> https://pypi.python.org/pypi/__six/1.3.0
> <https://pypi.python.org/pypi/six/1.3.0>

> my original response was from cell phone. I just answered that you
> can't do ifdefs, implying that there is no preprocessor in python. I
> learned a lot of things I didn't know reading the thread, but I wonder
> if it is a good idea in general to try to write code like this. --
> combined 2.x/3.x codebase can be a bear to maintain.

Many people have come to prefer a) a single 2&3 codebase over b)
separate 2 and 3 codebases or c) a single 2 codebase repeatedly
converted to a 3 codebase with 2to3.

They use 2to3 once (well, a few times) to discover differences that need
to be considered.

For 2.7 and 3.x, the future imports are enough for some code. The six
module handles harder cases.

> I wouldn't do it
> unless there was some imposing reason that I must. Its not just print()
> -- that isn't bad, but changes in module names (urllib),

I believe six handles that

> arithmetic, and

from __future__ import integer_division # spelling?
handles the only change

> unicode

Use unicode consistently and
from __future__ import unicode_literals # spelling?
or the re-addition u'' prefix do quite well.

Otherwise, do not use things that evaporated, like apply() and classic
classes. (Inherit from object if nothing else.)

This is all hearsay coming from me ;-).

Terry


Steven D'Aprano

unread,
May 28, 2013, 8:57:10 PM5/28/13
to
On Tue, 28 May 2013 18:25:59 -0400, Joel Goldstick wrote:

> I wonder
> if it is a good idea in general to try to write code like this. --
> combined 2.x/3.x codebase can be a bear to maintain.

Not so much a bear as a tiny little kitten.


> I wouldn't do it
> unless there was some imposing reason that I must. Its not just print()
> -- that isn't bad, but changes in module names (urllib), arithmetic, and
> unicode especially make this idea in general, very tricky. Pity the
> next developer who needs to try to maintain it.

It's not that hard really. Well, like all things, it depends on the
circumstances. If you're reliant on external modules, you *may* have a
bad time if those modules are 2.x only or 3.x only, but the standard
library and built-ins don't provide too much of a challenge.

There's no doubt that supporting 2.x and 3.x in one code base is more
difficult that just supporting one or the other, but the difficulty is
much less than often supposed. Python 2.7, and to a lesser extent, 2.6,
are designed to be as easy to port to 3.x as possible, which has the
happy side-effect that they are also relatively easy to write code for
them that will also run under 3.x.

Many of the differences can be eliminated with a few __future__ imports:

from __future__ import division, print_function


Differences in behaviour of the built-ins can be eliminated:

from future_builtins import *


Built-ins such as reduce and cmp that have been moved, or eliminated, can
easily be restored:

if sys.version >= '3':
from functools import reduce


Or if you prefer a "Better To Ask Forgiveness Than Permission" approach:

try:
reduce
except NameError:
from functools import reduce


Name changes of modules are easy to deal with:

try:
import configparser
except ImportError:
import ConfigParser as configparser


The most difficult difference is the difference between strings in 2.x
and 3.x, but if you drop support for Python 3.1 and 3.2, you can write
code that works in both 2.7 and 3.3 by using the u"" syntax. Or just use
ASCII literals, which work perfectly in both.

There are really only a very few things that cannot be shared between 2.x
and 3.x: syntactical features that are only supported by 3.x. So if
you're planning on writing code that runs in both 2.x and 3.x, you need
to eschew the 3-only features like keyword-only function arguments and
function annotations.

But that's no different than writing code to support *any* two versions
that don't have identical syntax. E.g. 2.4 and 2.5: 2.5 supports ternary
if, `a if condition else b`, while 2.4 does not, so if you need to
support both, you can't use ternary if. Nearly all the code I write is
for 2.4 or better, and I can assure you that the hardest part is
supporting 2.4. Adding 3.x doesn't make it much harder.

(My hat goes off to those supporting 2.3 through 3.3 in one code base.
That is, frankly, astonishing.)

Nobody *likes* to have to support really old versions missing the cool
syntax that you want to use, but nobody says that you should even try.
3.x doesn't change that.



--
Steven

Dan Stromberg

unread,
May 28, 2013, 9:23:33 PM5/28/13
to Carlos Nepomuceno, pytho...@python.org


Here're slides from a presentation about writing code that runs on 2.x and 3.x: http://stromberg.dnsalias.org/~dstromberg/Intro-to-Python/

And in case you still want a preprocessor for Python (you likely don't need one this time), here's an example of doing this using the venerable m4: https://pypi.python.org/pypi/red-black-tree-mod .  Note the many comments added to keep line numbers consistent.

Sent from my android phone.

On May 28, 2013 12:47 PM, "Carlos Nepomuceno" <carlosne...@outlook.com> wrote:
Are there Python 'preprocessor directives'?

I'd like to have something like '#ifdef' to mix code from Python 2 and 3 in a single file.

Grant Edwards

unread,
May 29, 2013, 10:45:37 AM5/29/13
to
On 2013-05-28, Carlos Nepomuceno <carlosne...@outlook.com> wrote:

> How do you have "inv...@invalid.invalid" instead of your email address?

I have this in my .slrnrc:

set hostname "invalid.invalid"
set username "grant"
set realname "Grant Edwards"

I'm not sure why it doesn't show up as gr...@invalid.invalid -- I
think it used to.

Since I'm this as a Usenet news group using the slrn newsreader
program, there's no need to make my email address visible in the
message headers in a usable form. I originally did this long ago
(probably 20 years) to avoid spam. I'm pretty sure that it's all in
vain these days, and the spam filters at Google are what's keeping me
from drowning.

--
Grant Edwards grant.b.edwards Yow! Gee, I feel kind of
at LIGHT in the head now,
gmail.com knowing I can't make my
satellite dish PAYMENTS!

Grant Edwards

unread,
May 29, 2013, 10:55:18 AM5/29/13
to
On 2013-05-29, Dan Stromberg <drsa...@gmail.com> wrote:

> And in case you still want a preprocessor for Python (you likely don't need
> one this time), here's an example of doing this using the venerable m4:
> https://pypi.python.org/pypi/red-black-tree-mod . Note the many comments
> added to keep line numbers consistent.

I was wondering whether or not to mention m4. Since m4 is (in my
mind) inextricably linked to RATFOR and sendmail config files I try
to avoid thinking about it lest the flashbacks start again...

--
Grant Edwards grant.b.edwards Yow! Hmmm ... a CRIPPLED
at ACCOUNTANT with a FALAFEL
gmail.com sandwich is HIT by a
TROLLEY-CAR ...

Chris Angelico

unread,
May 29, 2013, 11:05:35 AM5/29/13
to pytho...@python.org
On Thu, May 30, 2013 at 12:55 AM, Grant Edwards <inv...@invalid.invalid> wrote:
> On 2013-05-29, Dan Stromberg <drsa...@gmail.com> wrote:
>
>> And in case you still want a preprocessor for Python (you likely don't need
>> one this time), here's an example of doing this using the venerable m4:
>> https://pypi.python.org/pypi/red-black-tree-mod . Note the many comments
>> added to keep line numbers consistent.
>
> I was wondering whether or not to mention m4. Since m4 is (in my
> mind) inextricably linked to RATFOR and sendmail config files I try
> to avoid thinking about it lest the flashbacks start again...

It's not a bad tool. I used it as a sort of PHP preprocessor, because
requirements at work had me wanting to have a source file defining a
PHP class and having an autogenerated section in the middle of that
class. PHP's 'include' directive doesn't work for that. Of course, had
we been using a better language, that wouldn't have been an issue (and
it stopped being an issue when we improved the design and stopped
using that class system, too, though I retained the makefile
directives about building .php.m4 -> .php files). But still, GNU M4 is
a decent piece of technology.

ChrisA

Grant Edwards

unread,
May 29, 2013, 11:25:56 AM5/29/13
to
On 2013-05-29, Chris Angelico <ros...@gmail.com> wrote:
> On Thu, May 30, 2013 at 12:55 AM, Grant Edwards <inv...@invalid.invalid> wrote:
>> On 2013-05-29, Dan Stromberg <drsa...@gmail.com> wrote:
>>
>>> And in case you still want a preprocessor for Python (you likely don't need
>>> one this time), here's an example of doing this using the venerable m4:
>>> https://pypi.python.org/pypi/red-black-tree-mod . Note the many comments
>>> added to keep line numbers consistent.
>>
>> I was wondering whether or not to mention m4. Since m4 is (in my
>> mind) inextricably linked to RATFOR and sendmail config files I try
>> to avoid thinking about it lest the flashbacks start again...
>
> It's not a bad tool. I used it as a sort of PHP preprocessor,
> [...]
> But still, GNU M4 is a decent piece of technology.

I didn't mean to disparage m4 -- it always seemed well thought out and
useful. It just happens to be associated with unpleasant things for
me. [And it didn't really seem like a good option for the OP's
problem.]

Still, if one really did want a preprocessor for Python programs, m4
would be the first thing I'd look at.

--
Grant Edwards grant.b.edwards Yow! I wonder if I ought
at to tell them about my
gmail.com PREVIOUS LIFE as a COMPLETE
STRANGER?

Erik Max Francis

unread,
Jun 2, 2013, 7:57:02 PM6/2/13
to
On 05/29/2013 08:05 AM, Chris Angelico wrote:
> It's not a bad tool. I used it as a sort of PHP preprocessor, because
> requirements at work had me wanting to have a source file defining a
> PHP class and having an autogenerated section in the middle of that
> class. PHP's 'include' directive doesn't work for that. Of course, had
> we been using a better language, that wouldn't have been an issue (and
> it stopped being an issue when we improved the design and stopped
> using that class system, too, though I retained the makefile
> directives about building .php.m4 -> .php files). But still, GNU M4 is
> a decent piece of technology.

Agreed. The terror that most people feel when hearing "m4" is because
m4 was associated with sendmail, not because m4 was inherently awful.
It has problems, but you'd only encounter them when doing something
_very_ abstract.

--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Jabber erikmaxfrancis
Substance is one of the greatest of our illusions.
-- Sir Arthur Eddington

Roy Smith

unread,
Jun 2, 2013, 8:23:14 PM6/2/13
to
In article <n4mdnZkIOrRTRjbM...@giganews.com>,
Erik Max Francis <m...@alcyone.com> wrote:

> On 05/29/2013 08:05 AM, Chris Angelico wrote:
> > It's not a bad tool. I used it as a sort of PHP preprocessor, because
> > requirements at work had me wanting to have a source file defining a
> > PHP class and having an autogenerated section in the middle of that
> > class. PHP's 'include' directive doesn't work for that. Of course, had
> > we been using a better language, that wouldn't have been an issue (and
> > it stopped being an issue when we improved the design and stopped
> > using that class system, too, though I retained the makefile
> > directives about building .php.m4 -> .php files). But still, GNU M4 is
> > a decent piece of technology.
>
> Agreed. The terror that most people feel when hearing "m4" is because
> m4 was associated with sendmail

Arrrrggghhh. You had to go and dredge up those bad memories? I hadn't
thought about sendmail config files in years. I'll probably never be
able to get to sleep tonight.

Skip Montanaro

unread,
Jun 2, 2013, 8:29:17 PM6/2/13
to Erik Max Francis, Python

> The terror that most people feel when hearing "m4" is because m4 was associated with sendmail, not because m4 was inherently awful.

In fact, m4 made sendmail configs easier to maintain.

Skip

Chris Angelico

unread,
Jun 2, 2013, 10:05:49 PM6/2/13
to pytho...@python.org
On Mon, Jun 3, 2013 at 9:57 AM, Erik Max Francis <m...@alcyone.com> wrote:
> On 05/29/2013 08:05 AM, Chris Angelico wrote:
>>
>> It's not a bad tool. I used it as a sort of PHP preprocessor, because
>> requirements at work had me wanting to have a source file defining a
>> PHP class and having an autogenerated section in the middle of that
>> class. PHP's 'include' directive doesn't work for that. Of course, had
>> we been using a better language, that wouldn't have been an issue (and
>> it stopped being an issue when we improved the design and stopped
>> using that class system, too, though I retained the makefile
>> directives about building .php.m4 -> .php files). But still, GNU M4 is
>>
>> a decent piece of technology.
>
>
> Agreed. The terror that most people feel when hearing "m4" is because m4
> was associated with sendmail, not because m4 was inherently awful. It has
> problems, but you'd only encounter them when doing something _very_
> abstract.

Ah. I actually wasn't aware of m4's use with sendmail. I first met it
as the aforementioned PHP preprocessor, simply by Googling for
something along the lines of "generic preprocessor". First hit solved
my problems.

ChrisA

Chris Angelico

unread,
Jun 12, 2013, 4:42:22 PM6/12/13
to pytho...@python.org
On Tue, Jun 4, 2013 at 8:18 AM, Carlos Nepomuceno
<carlosne...@outlook.com> wrote:
> ----------------------------------------
>> Date: Mon, 3 Jun 2013 12:05:49 +1000
>> Subject: Re: Python #ifdef
>> From: ros...@gmail.com
>> To: pytho...@python.org
> [...]
>> Ah. I actually wasn't aware of m4's use with sendmail. I first met it
>> as the aforementioned PHP preprocessor, simply by Googling for
>> something along the lines of "generic preprocessor". First hit solved
>> my problems.
>>
>> ChrisA
>
> Why didn't you use something like EZT[1]?
>
> [1] https://code.google.com/p/ezt/

I'm a bit behind getting to this; I think some python-list posts got
stuck somewhere (maybe in the news->list gateway?). Anyway: The reason
I didn't was simply that m4 came up first. I was familiar with the C
preprocessor and PPWizard (which is designed for HTML), and simply
went looking for a generic one. And yes, I had seriously contemplated
using the C preprocessor (from gcc), but there was a reason not to
(don't remember now, but I'm guessing it'll be the conflict between
hash comments in PHP and hash directives to cpp).

ChrisA
0 new messages