python and macros (again) [Was: python3: 'where' keyword]

Discussion in 'Python' started by michele.simionato@gmail.com, Jan 11, 2005.

  1. Guest

    Paul Rubin wrote:
    > How about macros? Some pretty horrible things have been done in C
    > programs with the C preprocessor. But there's a movememnt afloat to
    > add hygienic macros to Python. Got any thoughts about that?


    "Movement" seems quite an exaggeration. Maybe 2-3 people made some
    experiments, but nobody within the core Python developers seems
    to be willing to advocate the introduction of macros.

    > Why should you care whether the output of a macro is ugly or not,
    > if no human is ever going to look at it?


    But at least some human eye have to look at it!
    <rethorical-question>
    Did you ever debug a macro?
    </rethorical-question>

    More seriuosly, I have given some thought to the issue, and I am very
    much against the introduction of macros in Python.

    Here are a few reasons:

    1. I like defmacro in Lisp. Problem is, Lisp is an s-expression based
    language, Python is not. We cannot implement defmacro in Python and
    even if we could, if would be too ugly to be used (at least, IMHO).

    2. One could proposed hygienic pattern-matching macros in Python,
    similar to
    Scheme syntax-rules macros. Again, it is not obvious how to
    implement pattern-matching in Python in a non-butt-ugly way. Plus,
    I feel hygienic macros quite limited and not worth the effort.

    3. We would add to Python the learning curve of macros and their
    subtilities and we do not want it.

    4. Macros would complicate a lot Python module system.

    5. We have Guido providing a good syntax for us all, why we should be
    fiddling with it? More seriously, if some verbosity is recognized
    in the language (think to the "raison d'etre" of decorators, for
    instance) I very much prefer to wait for Guido to take care of
    that, once and for all, than having 100 different custom made
    solutions based on macros.

    I am sure I could find other reasons if I think a bit more, but these
    should suffice for the moment ;)

    What I would be interested in is a Lisp/Scheme implementation
    compiling to Python bytecode, but I am not aware of any project
    in that direction.


    Michele Simionato

    P.S. some pointers for people interested on the topic:

    http://logix.livelogix.com/ (a Python-like language with macros)
    https://sourceforge.net/projects/pymac/ (an experimental
    Dylan-inspired macro system for Python)
    , Jan 11, 2005
    #1
    1. Advertising

  2. Paul Rubin Guest

    writes:
    > 2. One could proposed hygienic pattern-matching macros in Python,
    > similar to
    > Scheme syntax-rules macros. Again, it is not obvious how to
    > implement pattern-matching in Python in a non-butt-ugly way. Plus,
    > I feel hygienic macros quite limited and not worth the effort.


    It wasn't obvious how to do it in Scheme either. There was quite
    a bit of head scratching and experimental implementation before
    there was consensus.

    > 3. We would add to Python the learning curve of macros and their
    > subtilities and we do not want it.


    I can't imagine how it could be worse than the learning curve of
    __metaclass__, which we already have. If it was done in a way that
    most of us would just rely on a few standard ones, that would be fine.

    > 4. Macros would complicate a lot Python module system.


    I don't see how, but maybe I'm missing something.

    > 5. We have Guido providing a good syntax for us all, why we should be
    > fiddling with it? More seriously, if some verbosity is recognized
    > in the language (think to the "raison d'etre" of decorators, for
    > instance) I very much prefer to wait for Guido to take care of
    > that, once and for all, than having 100 different custom made
    > solutions based on macros.


    Every time some newbie asks an innocent "how do I ..." question, we
    see unbelievably horrid answers from gurus. Just check the FAQ about
    conditional expressions, etc. I just don't see Python syntax changes
    as forthcoming.

    > What I would be interested in is a Lisp/Scheme implementation
    > compiling to Python bytecode, but I am not aware of any project
    > in that direction.


    But that sounds like a bizarre idea. Python bytecode is just a
    CPython artifact, not part of the language. And it's not even that
    good an artifact. Good Lisp/Scheme implementations compile to native
    code that beats the pants off of CPython bytecode. It would make much
    more sense to have a Python implementation that compiles Python to
    S-expressions and then lets a high performance Lisp or Scheme system
    take care of the rest.
    Paul Rubin, Jan 11, 2005
    #2
    1. Advertising

  3. Guest

    Re: python and macros (again) [Was: python3: 'where' keyword]

    Paul Rubin:
    > writes:


    >> <about Scheme macros>


    > It wasn't obvious how to do it in Scheme either. There was quite
    > a bit of head scratching and experimental implementation before
    > there was consensus.


    Actually I am not convinced there is consensus yet, i.e. there is a
    non-negligible minority of schemers convinced that original Lisp
    macros where better, not to talk of common lispers ;)

    >> 3. We would add to Python the learning curve of macros and their
    >> subtilities and we do not want it.


    > I can't imagine how it could be worse than the learning curve of
    > __metaclass__, which we already have.


    To me, learning macros *and their subtilities* was much more difficult
    than learning metaclasses.

    >> 4. Macros would complicate a lot Python module system.


    > I don't see how, but maybe I'm missing something.


    Go to comp.lang.scheme and google for "macros and module system";
    you will get everything you want to know and much more!

    >> 5. We have Guido providing a good syntax for us all, why we should

    be
    >> fiddling with it? More seriously, if some verbosity is recognized
    >> in the language (think to the "raison d'etre" of decorators, for
    >> instance) I very much prefer to wait for Guido to take care of
    >> that, once and for all, than having 100 different custom made
    >> solutions based on macros.


    > Every time some newbie asks an innocent "how do I ..." question, we
    > see unbelievably horrid answers from gurus. Just check the FAQ about
    > conditional expressions, etc. I just don't see Python syntax changes
    > as forthcoming.


    Well, I see this as a positive fact. If a syntax is contrived (such as
    a ternary
    operator, for instance) it is better *not* to have it than to have one
    hundred custom
    made syntaxes. At the end, we are just talking about syntax sugar here,
    not about
    lack of functionality.

    >> What I would be interested in is a Lisp/Scheme implementation
    >> compiling to Python bytecode, but I am not aware of any project
    >> in that direction.


    > But that sounds like a bizarre idea. Python bytecode is just a
    > CPython artifact, not part of the language. And it's not even that
    > good an artifact. Good Lisp/Scheme implementations compile to native
    > code that beats the pants off of CPython bytecode. It would make much
    > more sense to have a Python implementation that compiles Python to
    > S-expressions and then lets a high performance Lisp or Scheme system
    > take care of the rest.


    This is a bizarre idea if you want to make Python run faster. It is not
    so bizarre
    if what you want is to have access to Python from Lisp/Scheme in the
    same sense
    Jython has access to Java.


    Michele Simionato
    , Jan 12, 2005
    #3
  4. Re: python and macros (again) [Was: python3: 'where' keyword]

    writes:

    > This is a bizarre idea if you want to make Python run faster. It is
    > not so bizarre if what you want is to have access to Python from
    > Lisp/Scheme in the same sense Jython has access to Java.


    And it sounds very nice if you prefer writing Lisp code (or resort to
    it if needed) and run it on a cross-platform environment that's
    available almost everywhere, and access a large standard library of
    modern utilities.


    br,
    S
    Simo Melenius, Jan 12, 2005
    #4
  5. Paul Rubin Guest

    Re: python and macros (again) [Was: python3: 'where' keyword]

    writes:
    > > I can't imagine how it could be worse than the learning curve of
    > > __metaclass__, which we already have.

    >
    > To me, learning macros *and their subtilities* was much more difficult
    > than learning metaclasses.


    I guess I've only used Lisp macros in pretty straightforward ways,
    that weren't hard to understand. That's enough for anything I've
    needed. But we don't hear much about __metaclass__ because almost
    nobody understands it.

    > Go to comp.lang.scheme and google for "macros and module system";
    > you will get everything you want to know and much more!


    OK, I might do this.

    > Well, I see this as a positive fact. If a syntax is contrived (such
    > as a ternary operator, for instance) it is better *not* to have it
    > than to have one hundred custom made syntaxes. At the end, we are
    > just talking about syntax sugar here, not about lack of
    > functionality.


    I think the idea is there would be some experimentation and then one of
    the versions would make it into the standard library.

    > > [compiling Lisp to Python bytecode]

    > This is a bizarre idea if you want to make Python run faster. It is
    > not so bizarre if what you want is to have access to Python from
    > Lisp/Scheme in the same sense Jython has access to Java.


    Why not just use a foreign function interface?
    Paul Rubin, Jan 12, 2005
    #5
  6. Steve Holden Guest

    Paul Rubin wrote:

    > writes:
    >
    >>2. One could proposed hygienic pattern-matching macros in Python,
    >>similar to
    >>Scheme syntax-rules macros. Again, it is not obvious how to
    >>implement pattern-matching in Python in a non-butt-ugly way. Plus,
    >>I feel hygienic macros quite limited and not worth the effort.

    >
    >
    > It wasn't obvious how to do it in Scheme either. There was quite
    > a bit of head scratching and experimental implementation before
    > there was consensus.
    >
    >
    >>3. We would add to Python the learning curve of macros and their
    >>subtilities and we do not want it.

    >
    >
    > I can't imagine how it could be worse than the learning curve of
    > __metaclass__, which we already have. If it was done in a way that
    > most of us would just rely on a few standard ones, that would be fine.
    >

    Well the necessity to understand metaclasses could in some ways be
    regarded as the push for the summit, and therefore isn't something that
    would trouble newbies. Given that we are having this discussion in the
    context of a posited "where" clause intended to allow "multi-statement
    expressions" (whatever they turn out to be) I would still argue you are
    discussing the totally unnecessary.

    Given that Guido is on record as saying that expressions aren't
    statements because he wants those things to be separate, I don't really
    see why there's this consistent pressure to reverse that decision.

    >
    >>4. Macros would complicate a lot Python module system.

    >
    >
    > I don't see how, but maybe I'm missing something.
    >
    >
    >>5. We have Guido providing a good syntax for us all, why we should be
    >>fiddling with it? More seriously, if some verbosity is recognized
    >>in the language (think to the "raison d'etre" of decorators, for
    >>instance) I very much prefer to wait for Guido to take care of
    >>that, once and for all, than having 100 different custom made
    >>solutions based on macros.

    >
    >
    > Every time some newbie asks an innocent "how do I ..." question, we
    > see unbelievably horrid answers from gurus. Just check the FAQ about
    > conditional expressions, etc. I just don't see Python syntax changes
    > as forthcoming.
    >

    There's a reason for this ...
    >
    >>What I would be interested in is a Lisp/Scheme implementation
    >>compiling to Python bytecode, but I am not aware of any project
    >>in that direction.

    >
    >
    > But that sounds like a bizarre idea. Python bytecode is just a
    > CPython artifact, not part of the language. And it's not even that
    > good an artifact. Good Lisp/Scheme implementations compile to native
    > code that beats the pants off of CPython bytecode. It would make much
    > more sense to have a Python implementation that compiles Python to
    > S-expressions and then lets a high performance Lisp or Scheme system
    > take care of the rest.


    Which would be a worthier goal than trying to graft macros on to Python.
    You responded that macros would be difficult to implement in m4 because
    (in essence) of the indented structure of Python. I'm not convinced
    they'd be any easier in Python, and I'm *certainly* not convinced that
    their addition would improve Python's readability.

    At best it would offer new paradigms for existing constructs (violating
    the "there should be one obvious way to do it" zen); at worst it would
    obfuscate the whole language.

    If you really see the need for Python macros then a preprocessor would
    surely be the best way to prove the validity of such ideas?

    regards
    Steve
    --
    Steve Holden http://www.holdenweb.com/
    Python Web Programming http://pydish.holdenweb.com/
    Holden Web LLC +1 703 861 4237 +1 800 494 3119
    Steve Holden, Jan 12, 2005
    #6
  7. Steve Holden Guest

    Re: python and macros (again) [Was: python3: 'where' keyword]

    Paul Rubin wrote:

    > writes:
    >
    >>>I can't imagine how it could be worse than the learning curve of
    >>>__metaclass__, which we already have.

    >>
    >>To me, learning macros *and their subtilities* was much more difficult
    >>than learning metaclasses.

    >
    >
    > I guess I've only used Lisp macros in pretty straightforward ways,
    > that weren't hard to understand. That's enough for anything I've
    > needed. But we don't hear much about __metaclass__ because almost
    > nobody understands it.
    >

    Paraphrasing Tim Peters, "if you don't definitely know that you need
    metaclasses then you almost certainly don't". The primary reason for the
    existence of metaclasses is as an implementation detail that allows
    basic Python types to be base classes for inheritance. Python could have
    hidden this mechanism, but the generally introspective nature of the
    language makes it sensible to expose the mechanism for (ab)use by
    knowledgeable users.
    >
    >>Go to comp.lang.scheme and google for "macros and module system";
    >>you will get everything you want to know and much more!

    >
    >
    > OK, I might do this.
    >

    Well I'd be interested to know what you find out, not being a Lisper myself.
    >
    >>Well, I see this as a positive fact. If a syntax is contrived (such
    >>as a ternary operator, for instance) it is better *not* to have it
    >>than to have one hundred custom made syntaxes. At the end, we are
    >>just talking about syntax sugar here, not about lack of
    >>functionality.

    >
    >
    > I think the idea is there would be some experimentation and then one of
    > the versions would make it into the standard library.
    >

    Erm, you'd put syntax into a library module? That would be in
    __future__, I take it?
    >
    >>>[compiling Lisp to Python bytecode]

    >>
    >>This is a bizarre idea if you want to make Python run faster. It is
    >>not so bizarre if what you want is to have access to Python from
    >>Lisp/Scheme in the same sense Jython has access to Java.

    >
    >
    > Why not just use a foreign function interface?


    regards
    Steve
    --
    Steve Holden http://www.holdenweb.com/
    Python Web Programming http://pydish.holdenweb.com/
    Holden Web LLC +1 703 861 4237 +1 800 494 3119
    Steve Holden, Jan 12, 2005
    #7
  8. Op 2005-01-12, Steve Holden schreef <>:
    >
    > Given that Guido is on record as saying that expressions aren't
    > statements because he wants those things to be separate, I don't really
    > see why there's this consistent pressure to reverse that decision.


    Well, it seems that Guido is wrong then. The documentation clearly
    states that an expression is a statement.

    More specifically, everywhere you can use a statement, you can
    simply use an expression according to the python syntax.

    That makes the set of expressions a subset of the set of
    statements and thus makes an expression a statement.

    > Which would be a worthier goal than trying to graft macros on to Python.
    > You responded that macros would be difficult to implement in m4 because
    > (in essence) of the indented structure of Python. I'm not convinced
    > they'd be any easier in Python, and I'm *certainly* not convinced that
    > their addition would improve Python's readability.
    >
    > At best it would offer new paradigms for existing constructs (violating
    > the "there should be one obvious way to do it" zen); at worst it would
    > obfuscate the whole language.


    That zen is already broken. Look at the number of answers one gets
    if a newbee askes for a ternary operator. I think that a simple
    ternary operator or macro's with an official supported macro that
    implemented the ternary operator would have been far closer to
    the spirit of only having one obvious way than what we have now.

    --
    Antoon Pardon
    Antoon Pardon, Jan 13, 2005
    #8
  9. Antoon Pardon wrote:

    > Well, it seems that Guido is wrong then. The documentation clearly
    > states that an expression is a statement.


    no, it says that an expression statement is a statement. if you don't
    understand the difference, please *plonk* yourself.

    </F>
    Fredrik Lundh, Jan 13, 2005
    #9
  10. Op 2005-01-13, Fredrik Lundh schreef <>:
    > Antoon Pardon wrote:
    >
    >> Well, it seems that Guido is wrong then. The documentation clearly
    >> states that an expression is a statement.

    >
    > no, it says that an expression statement is a statement. if you don't
    > understand the difference, please *plonk* yourself.


    And what else is an expression statement but an expression (list) used
    as a statement.

    --
    Antoon Pardon
    Antoon Pardon, Jan 13, 2005
    #10
  11. Steve Holden Guest

    Fredrik Lundh wrote:

    > Antoon Pardon wrote:
    >
    >
    >>Well, it seems that Guido is wrong then. The documentation clearly
    >>states that an expression is a statement.

    >
    >
    > no, it says that an expression statement is a statement. if you don't
    > understand the difference, please *plonk* yourself.
    >

    OK then, "The documentation clearly states that not all statements can
    be expressions". Specifically Guido has justified the fact that an
    assignment does not return any value, and therefore cannot be used as a
    component of an expression.

    Mea culpa, but I'm not going to *plonk* myself - then *nobody* would be
    listening to me :)

    regards
    Steve
    --
    Steve Holden http://www.holdenweb.com/
    Python Web Programming http://pydish.holdenweb.com/
    Holden Web LLC +1 703 861 4237 +1 800 494 3119
    Steve Holden, Jan 13, 2005
    #11
  12. Craig Ringer Guest

    On Thu, 2005-01-13 at 08:39 +0000, Antoon Pardon wrote:

    > > At best it would offer new paradigms for existing constructs (violating
    > > the "there should be one obvious way to do it" zen); at worst it would
    > > obfuscate the whole language.

    >
    > That zen is already broken. Look at the number of answers one gets
    > if a newbee askes for a ternary operator. I think that a simple
    > ternary operator or macro's with an official supported macro that
    > implemented the ternary operator would have been far closer to
    > the spirit of only having one obvious way than what we have now.


    And then we have iteration ....

    (generator expressions, list comprehensions, for loops, ...?) over
    (sequences, iterators, generators)

    I happen to be extremely fond of the flexibility this provides, but one
    obvious way to do it there is not.

    --
    Craig Ringer
    Craig Ringer, Jan 13, 2005
    #12
  13. Terry Reedy Guest

    "Antoon Pardon" <> wrote in message
    news:...
    > Op 2005-01-13, Fredrik Lundh schreef <>:
    >> Antoon Pardon wrote:
    >>
    >>> Well, it seems that Guido is wrong then. The documentation clearly
    >>> states that an expression is a statement.

    >>
    >> no, it says that an expression statement is a statement. if you don't
    >> understand the difference, please *plonk* yourself.

    >
    > And what else is an expression statement but an expression (list) used
    > as a statement.


    Whereas an expression used within a statement is not a statement, and that
    is the difference.

    And of course, statements, in general, are not expressions and are not used
    within statements (except within compound statements).

    Terry J. Reedy
    Terry Reedy, Jan 13, 2005
    #13
  14. Paul Rubin Guest

    "Terry Reedy" <> writes:
    > >>> Well, it seems that Guido is wrong then. The documentation clearly
    > >>> states that an expression is a statement.
    > >>
    > >> no, it says that an expression statement is a statement. if you don't
    > >> understand the difference, please *plonk* yourself.

    > >
    > > And what else is an expression statement but an expression (list) used
    > > as a statement.

    >
    > Whereas an expression used within a statement is not a statement, and that
    > is the difference.


    Huh? Expressions are not statements except when they're "expression
    statements"? What kind of expression is not an expression statement?
    And logic would indicate that if we can separate statements from
    expressions and still have "expression statements", nothing stops
    us from also being able to have "statement expressions".
    Paul Rubin, Jan 13, 2005
    #14
  15. On Thu, 13 Jan 2005 09:29:49 -0500, Steve Holden <> wrote:

    >Fredrik Lundh wrote:
    >
    >> Antoon Pardon wrote:
    >>
    >>
    >>>Well, it seems that Guido is wrong then. The documentation clearly
    >>>states that an expression is a statement.

    >>
    >>
    >> no, it says that an expression statement is a statement. if you don't
    >> understand the difference, please *plonk* yourself.
    >>

    >OK then, "The documentation clearly states that not all statements can
    >be expressions". Specifically Guido has justified the fact that an
    >assignment does not return any value, and therefore cannot be used as a
    >component of an expression.
    >

    Hm, that makes me wonder, is there an intermediate "returning of value" in
    x = y = z = 123
    ?

    >Mea culpa, but I'm not going to *plonk* myself - then *nobody* would be
    >listening to me :)


    Regards,
    Bengt Richter
    Bengt Richter, Jan 13, 2005
    #15
  16. Paul Rubin wrote:

    > Huh? Expressions are not statements except when they're "expression
    > statements"? What kind of expression is not an expression statement?


    any expression that is used in a content that is not an expression statement,
    of course.

    reading the python language reference should help you sort this one out.

    </F>
    Fredrik Lundh, Jan 13, 2005
    #16
  17. Bengt Richter wrote:

    > Hm, that makes me wonder, is there an intermediate "returning of value" in
    > x = y = z = 123
    > ?


    no. that statement evaluates the expression (123 in this case), and assigns
    the result (the integer object 123) to each target (x, y, z), in order. or to
    quote the language reference:

    An assignment statement evaluates the expression list (remember
    that this can be a single expression or a comma-separated list, the
    latter yielding a tuple) and assigns the single resulting object to each
    of the target lists, from left to right.

    </F>
    Fredrik Lundh, Jan 13, 2005
    #17
  18. Paul Rubin Guest

    "Fredrik Lundh" <> writes:
    > > Huh? Expressions are not statements except when they're "expression
    > > statements"? What kind of expression is not an expression statement?

    >
    > any expression that is used in a content that is not an expression statement,
    > of course.


    Come on, that is vacuous. The claim was "expressions are not
    statements". But it turns out that expressions ARE statements. The
    explanation is "well, that's because they're expression statements".
    And there is no obvious case of an expression that can't be used as a
    statement. So it's not inherently obvious that there needs to be any
    kind of statement that can't be used as an expression. It's just an
    artifact. Whether the artifact is a desirable one is a matter of
    discussion.
    Paul Rubin, Jan 13, 2005
    #18
  19. Nick Coghlan Guest

    Paul Rubin wrote:
    > Come on, that is vacuous. The claim was "expressions are not
    > statements". But it turns out that expressions ARE statements. The
    > explanation is "well, that's because they're expression statements".
    > And there is no obvious case of an expression that can't be used as a
    > statement. So it's not inherently obvious that there needs to be any
    > kind of statement that can't be used as an expression. It's just an
    > artifact. Whether the artifact is a desirable one is a matter of
    > discussion.


    No, it's entirely to do with building a readable language that uses significant
    whitespace to delineate scope.

    Simple statements are not allowed to contain other statements, but they are
    allowed to contain expressions. In their most degenerate form, ALL they contain
    is a *single* expression (e.g. a function call). That expression itself is still
    not a statement, though. Think of it as the difference between value and [value].

    Suites are sequences of statements.

    Compound statements are statements which incorporate a suite as part of their
    syntax.

    Python allows statements inside suites and suites inside compound statements. It
    also allows expressions inside statements and expressions inside expressions.
    The one thing it never ever does is allow a suite or a statement inside an
    expression, because doing so would utterly destroy the handling of significant
    white space.

    And that's why expressions are special in Python - they demarcate the boundary
    of the significance of whitespace. Within an expression, whitespace is
    insignificant. At the level of statements and suites, whitespace is extremely
    significant.

    So, precisely how should one go about cleanly embedding something that cares
    about whitespace into a context which doesn't care in the slightest?

    Cheers,
    Nick.

    --
    Nick Coghlan | | Brisbane, Australia
    ---------------------------------------------------------------
    http://boredomandlaziness.skystorm.net
    Nick Coghlan, Jan 14, 2005
    #19
  20. Paul Rubin Guest

    Nick Coghlan <> writes:
    > So, precisely how should one go about cleanly embedding something that
    > cares about whitespace into a context which doesn't care in the
    > slightest?


    Treat the macro like a function call whose arguments are thunks made
    from the macro arguments, or something like that. There's been some
    discussions about it on clpy in the past, by people more into this
    stuff than I am.
    Paul Rubin, Jan 14, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    80
    Views:
    2,360
    Stephen J. Bevan
    Nov 7, 2003
  2. Replies:
    1
    Views:
    429
    Marco Antoniotti
    Oct 7, 2003
  3. Replies:
    5
    Views:
    484
  4. Michael T. Babcock

    Re: Explanation of macros; Haskell macros

    Michael T. Babcock, Nov 3, 2003, in forum: Python
    Replies:
    0
    Views:
    505
    Michael T. Babcock
    Nov 3, 2003
  5. Andrew Berg
    Replies:
    0
    Views:
    322
    Andrew Berg
    Jun 16, 2012
Loading...

Share This Page