HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
lihaoyi
macropy
TSQL2013–2025
lihaoyi / macropy

macropy

Macros in Python: quasiquotes, case classes, LINQ and more!

26Distinct people
48Mentions
0Explicit recommenders
3.3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Macros in Python: quasiquotes, case classes, LINQ and more!

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year48 dated mentions

Observed mentions: 2013-04-23 23:49:42 UTC to 2025-11-29 13:41:51 UTC.

05101520252013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 23 mentions; 13 submissions, 10 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC231310
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC404
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC413
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC303
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC312
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC303
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC303
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
MacroPy3 1.1.0b2 MacroPy is an implementation of Syntactic Macros in the Python Programming Language. MacroPy provides a mechanism for user-defined functions (macros) to perform transformations on the abstract syntax tree (AST) of a Python program at import time. This is an easy way to enhance the semantics of a Python program in ways which are otherwise impossible, for example providing an extremely concise way of declaring classes. Python like you've never seen before MacroPy allows you to create constructs which are impossible to have in normal python code, such as: Tracing with trace: sum([x + 5 for x in range(3)]) # sum([x + 5 for x in range(3)]) # range(3) -> [0, 1, 2] # x + 5 -> 5 # x + 5 -> 6 # x + 5 -> 7 # [x + 5 for x in range(3)] -> [5, 6, 7] # sum([x + 5 for x in range(3)]) -> 18 Quick Lambdas print(list(map(f[_[0]], ['omg', 'wtf', 'bbq']))) # ['o', 'w', 'b'] print(list(reduce(f[_ + _], ['omg', 'wtf', 'bbq']))) # 'omgwtfbbq Case Classes @case class Point(x, y): pass p = Point(1, 2) print str(p) #Point(1, 2) print p.x #1 print p.y #2 print Point(1, 2) == Point(1, 2) # True and more! See the docs at http://macropy3.readthedocs.io/en/latest/. Requirements MacroPy3 is tested to run on CPython 3.4 or newer and PyPy 3.5. I has no current support for Jython. MacroPy3 is also available on PyPI. Installation Just execute a: $ pip install macropy3 if you want to use macros that require external libraries in order to work, you can automatically install those dependencies by installing one of the pinq or pyxl extras like this: $ pip install macropy3[pinq,pyxl] then have a look at the docs at http://macropy3.readthedocs.io/en/latest/. How to contribute We're open to contributions, so send us your ideas/questions/issues/pull-requests and we'll do our best to accommodate you! You can ask questions on the Google Group and on the Gitter channel or file bugs on thee issues page. Credits MacroPy was initially created as a final project for the MIT class 6.945: Adventures in Advanced Symbolic Programming, taught by Gerald Jay Sussman and Pavel Panchekha. Inspiration was taken from project such as Scala Macros, Karnickel and Pyxl. The MIT License (MIT) Copyright (c) 2013-2018, Li Haoyi, Justin Holmgren, Alberto Berti and all the other contributors Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Read the full README on GitHub

What Hacker News says

48 sources
C macros are just a text preprocessor. You could run the C preprocessor on a text file and have the result be Python code. Comments might be a little tricky, but it's doable. Or you can run a text file through a general-purpose one like m4. For sum types we have enums, and for product types we have tuples (or namedtuples or dataclasses). Sugar could be done with decorators or metaclasses. For Lisp macros, there's macropy and Hissp. https://www.gnu.org/software/m4/ https://threeofwands.com/algebraic-data-types-in-python/ https://github.com/lihaoyi/macropy https://github.com/gilch/hissp
In Ask HN: What are the nice feature you need in a programming language?
All the facilities to do that kind of metaprogramming are already there, it just takes some libraries to put them on your fingertips https://github.com/lihaoyi/macropy The "LISP is homoiconic" trope is oversimplified; the Python stdlib gives access to the compiler, parse trees, bytecode, etc. There are more moving parts, but with the edges sanded off syntactic macros should be comfortable in Python -- and take the burden of innovation off CPython and PyPy promoting simplicity there for the long term. The Python folks have been switching Python to a PEG grammar https://www.python.org/dev/peps/pep-0617/ At the moment I am little disappointed at the Py 3.10 source code because they haven't exposed the PEG parser to Python programmers yet as they promised. You could use this to do little stunts like adding an "unless x:" statement equ
Read the rest
ivalent to "if not x:" or write a parser for the strange query language your organization uses that lets you sort the dict's it returns to you in the same order you put the fields in the select clause...
In Python Enhancement Proposal 638 – Syntactic Macros
One of the failures of conventional programming libraries is that parsing libraries such as yacc work in only one direction. In 2018 we could easily have libraries that work both ways by default, but we don't. Bidirectional parsing is great for code generation and opens up a lot of things you could do easily, but because common parsing libraries are unidirectional, people aren't aware of what you can do and don't clamor for bidirectional parsing. It is very possible and practical to parse conventional languages down to an AST tree, work on the tree, and run that code. See https://github.com/lihaoyi/macropy Sometimes I wonder if the LISP cult is just trying to pretend Noam Chomsky was never born.
In Just what does “code as data” mean anyway? (2014)
> ... methods should be called with as many sets of parentheses as they are defined with (excluding implicits), and any method call missing parens should be eta-expanded into the appropriate function value. > Notably, removing the "optional parens" thing would not stop you from defining "property" functions that are called without parens; it would just mean you need to define such functions without parens, as is already possible. > In other languages with first-class functions, like Python, this 'works fine' [quotes mine] I'm not sure how this behaviour could be seen as 'more consistent'. If methods that have parens but are called with them stripped are eta-expanded but you can still define no-paren methods, you'd still have confusing behaviour where a no-paren method isn't eta-expanded as expected (because it's a property and so 'special
Read the rest
'). Rather than more consistent, this behaviour is just 'more like Python'[0], which has this inconsistency too[1]. Essentially the suggestion in the article would mean: @ def x() = 1 @ val y = x resXX: () => Int = $... @ def a = 1 @ val b = a resYY: Int = 1 It's also worth noting that IntelliJ IDEA (and possibly Eclipse) warn you if you define a no-argument method with Unit return type (since `def action()`s should have parens and `def pure` values needn't). IDEA will warn you (and offer to correct) if you call a method with too few parens (`def x()` called as `x` will display a very visible warning), so maybe there's some room to believe that this is a 'problem', but the solution involving automatic eta-expansion doesn't seem like a particularly sane one. Also, calling `getFoo` without parameters is 'nice to have', but calling `name()` as `name` and `color()` as `color` on imported Java APIs both comes across as more natural in Scala (since Java has no properties, they can't be defined as properties upstream) and has allowed quite a few Java APIs to fit in naturally in Scala where they wouldn't have otherwise, in my experience. [0]: All the eta-expansion things in this post are to 'be more like Python', which makes sense given Haoyi is also behind https://github.com/lampepfl/dotty/issues/2491 and https://github.com/lihaoyi/Scalite and (say) https://github.com/lihaoyi/macropy. [1]: Properties in Python also have the underlying design of using descriptors, which are a whole other world of horror.
In Warts of Scala

Showing the 15 most recent of 48 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.