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 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 8:01:28 AM 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

3 sources
> ... 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

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.