Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Macros in Python

github.com

Post reply on HN
Print view View original

21–30 of 71 posts

Re: Macros in Python

#21

Post by jnhnum1 »

drivingmenuts wrote: post #16

Something about classes that are nested inside other classes suddenly being available as top level classes seems wrong. I'm not super deep on the innards of Python, but that doesn't look right.

Other author here: Like lihaoyi said, it's true that the way we defined things doesn't match standard Python namespacing, but it saves some typing and I think it's easy to get used to the semantics of our case classes. Our macro just transforms the "namespace tree" that you would normally get from writing code like that into an "inheritance tree", where all the subclasses' names are at the level of the top class. If you wanted to do something like this with proper namespaces, you can probably do something similar without macros using metaclasses.

Re: Macros in Python

#22

Post by jnhnum1 »

lmm wrote: post #19
lihaoyi wrote: post #11

Earlier quoted context omitted.

Author here. If you look at my github, you'll see I do use plenty of Scala!

Well yes; the code is clearly the work of someone who uses and likes scala. My point was: the library seems designed to let you write "scala in python"; wouldn't it be better to use scala when you want scala syntax, and write more idiomatic python when using python?

Yes, probably if you're starting from scratch. But I think in general it's good to have a flexible language which lets you write code in any reasonable style. Hopefully this library (the AST transformation part, not the specific macros) is making Python even more Pythonic! Although I suspect Guido would disagree with me

Re: Macros in Python

#23

Post by pyre »

lihaoyi wrote: post #12
pyre wrote: post #10

Earlier quoted context omitted.

I'm sure there's a use-case for this, but I'm not coming up with one off the top of my head. This comes across as an extremely rare type of problem to encounter. What's the purpose of only binding x and z if the first argument of Bar matches? What if it doesn't match? Is an exception thrown? Are x,z just None? [Note: I'm talking about the example, not the @case decorator, which does seem useful] Edit: After reading t…

Author here. The ` The purposes of pattern matching is to replace code that looks like this: if (isinstance(tree, BinOp) and type(tree.left) is Name and type(tree.op) is Mod and tree.left.id in module.expr_registry): ... with code that looks like this if BinOp(Name(id), Mod(), body) Which looks much nicer, and more clearly says what you want: that `tree` "looks like" a particular shape. EDIT: Here's another example.…

Personally, I find those to be better 'real world' examples. I would suggest including them in the docs. Thanks for the explanation!

Re: Macros in Python

#24

Post by kruhft »

asm89 wrote: post #8
cheez wrote: post #2

Can anyone give a Tl;DR about how this works? Don't x and y need to exist beforehand?

It's hard to give a TL;DR on the whole library, but case classes can be used with for example pattern matching ( https://github.com/lihaoyi/macropy#pattern-matching ). The following code: with patterns: Foo(x, Bar(3, z)) The constructor after the Does this help? :)

That's known as destructuring-bind: http://www.lispworks.com/documentation/HyperSpec/Body/m_dest...

Is that a macro created by this library or a feature of the library?

Edit: I did some reading and it looks to be a feature macro of the library.

Re: Macros in Python

#25

Post by minamea »

jnhnum1 wrote: post #21
drivingmenuts wrote: post #16

Something about classes that are nested inside other classes suddenly being available as top level classes seems wrong. I'm not super deep on the innards of Python, but that doesn't look right.

Other author here: Like lihaoyi said, it's true that the way we defined things doesn't match standard Python namespacing, but it saves some typing and I think it's easy to get used to the semantics of our case classes. Our macro just transforms the "namespace tree" that you would normally get from writing code like that into an "inheritance tree", where all the subclasses' names are at the level of the top class. If…

I urge you to take this criticism more seriously. With your library a programmer is changing the semantics of class nesting in the language, all by pre-pending a very missable and ambiguous @case to the class. I'm no expert but I think this is pretty bad in any language, and especially one that says "explicit is better than implicit"

Re: Macros in Python

#27

Post by lihaoyi »

minamea wrote: post #25
jnhnum1 wrote: post #21

Earlier quoted context omitted.

Other author here: Like lihaoyi said, it's true that the way we defined things doesn't match standard Python namespacing, but it saves some typing and I think it's easy to get used to the semantics of our case classes. Our macro just transforms the "namespace tree" that you would normally get from writing code like that into an "inheritance tree", where all the subclasses' names are at the level of the top class. If…

I urge you to take this criticism more seriously. With your library a programmer is changing the semantics of class nesting in the language, all by pre-pending a very missable and ambiguous @case to the class. I'm no expert but I think this is pretty bad in any language, and especially one that says "explicit is better than implicit"

We do take it seriously; it's a hard tradeoff between Novelty and Utility. Given that the whole point of macros is to change the semantics of the Python language, this (valid) criticism applies not just to case classes but macros in general. If you go haywire with macros, all hell breaks loose.

We think that with some discipline, it is possible to come up with macro transformations which are both useful and understandable by a programmer. This means setting clearly defined semantics for the transformations, which is difficult but doable.

If you think macros are kinda crazy (well, they are!) you should look at the implementation of such pythonic constructs like `namedtuple`, the `ast` module and the new Enum library coming out!

Re: Macros in Python

#28

Post by shaddyz »

It's a cool idea, but this basically sneaks new features into the Python language through a backdoor, bypassing the public review/feedback process. I would suggest the author create a PEP for these features instead.

Re: Macros in Python

#29

Post by michaelhoffman »

lihaoyi wrote: post #27
minamea wrote: post #25

Earlier quoted context omitted.

I urge you to take this criticism more seriously. With your library a programmer is changing the semantics of class nesting in the language, all by pre-pending a very missable and ambiguous @case to the class. I'm no expert but I think this is pretty bad in any language, and especially one that says "explicit is better than implicit"

We do take it seriously; it's a hard tradeoff between Novelty and Utility. Given that the whole point of macros is to change the semantics of the Python language, this (valid) criticism applies not just to case classes but macros in general. If you go haywire with macros, all hell breaks loose. We think that with some discipline, it is possible to come up with macro transformations which are both useful and understan…

The implementation of namedtuple is pretty crazy, but the interface is simple and doesn't change the language semantics.

Re: Macros in Python

#30

Post by jnhnum1 »

minamea wrote: post #25
jnhnum1 wrote: post #21

Earlier quoted context omitted.

Other author here: Like lihaoyi said, it's true that the way we defined things doesn't match standard Python namespacing, but it saves some typing and I think it's easy to get used to the semantics of our case classes. Our macro just transforms the "namespace tree" that you would normally get from writing code like that into an "inheritance tree", where all the subclasses' names are at the level of the top class. If…

I urge you to take this criticism more seriously. With your library a programmer is changing the semantics of class nesting in the language, all by pre-pending a very missable and ambiguous @case to the class. I'm no expert but I think this is pretty bad in any language, and especially one that says "explicit is better than implicit"

Yes, it could be bad, but at the same time the "@case" isn't the only indicator that this class is special. A case class definition can be very visually distinct compared to a normal class.

One thing case classes let you do is implement functionality externally to a class using pattern-matching functions. When you do this, your case class definition will consist of nothing but empty class definitions:

  @case
  class List:
    class Nil():  pass
    class Cons(x, xs): pass
In any case, Python's enums will use fully qualified names, so we may change our current system for compatibility and consistency.
Post reply on HN