473,573 Members | 2,511 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

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

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)

Jul 18 '05 #1
37 2771
mi************* **@gmail.com 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.
Jul 18 '05 #2
Paul Rubin:
michele.simion. ..@gmail.com 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.schem e 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

Jul 18 '05 #3
mi************* **@gmail.com 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
Jul 18 '05 #4
mi************* **@gmail.com 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.schem e 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?
Jul 18 '05 #5
Paul Rubin wrote:
mi************* **@gmail.com 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
Jul 18 '05 #6
Paul Rubin wrote:
mi************* **@gmail.com 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.schem e 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
Jul 18 '05 #7
Op 2005-01-12, Steve Holden schreef <st***@holdenwe b.com>:

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
Jul 18 '05 #8
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>

Jul 18 '05 #9
Op 2005-01-13, Fredrik Lundh schreef <fr*****@python ware.com>:
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
Jul 18 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

220
18884
by: Brandon J. Van Every | last post by:
What's better about Ruby than Python? I'm sure there's something. What is it? This is not a troll. I'm language shopping and I want people's answers. I don't know beans about Ruby or have any preconceived ideas about it. I have noticed, however, that every programmer I talk to who's aware of Python is also talking about Ruby. So it...
699
33522
by: mike420 | last post by:
I think everyone who used Python will agree that its syntax is the best thing going for it. It is very readable and easy for everyone to learn. But, Python does not a have very good macro capabilities, unfortunately. I'd like to know if it may be possible to add a powerful macro system to Python, while keeping its amazing syntax, and if it...
852
28146
by: Mark Tarver | last post by:
How do you compare Python to Lisp? What specific advantages do you think that one has over the other? Note I'm not a Python person and I have no axes to grind here. This is just a question for my general education. Mark
0
7746
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
0
7668
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language...
0
7983
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. ...
0
8179
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
1
7735
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
0
6356
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
0
5257
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
0
3694
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
0
992
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.