[Python-ideas] Arbitrary constants in ASTs

[Haoyi Li]

As someone who's re-implemented this myself (not as performantly as a
dedicated opcode, but what the hell) using hygienic macros (
https://github.com/lihaoyi/macropy#interned), I think it's a neat idea,
but...

How many other people in the world are doing AST manipulations to want
this? I know I could use it, but I suspect I'm part of a very (very) small
pool of developers who would use this kind of functionality. For what it's
worth, my implementation using pickling in order to serialize the object(s)
being passed in, and inserts a (hygienically renamed) top-level
unpickle-and-assign statement into the module being worked with and
references to that value are just Name() nodes referencing the value
assigned.

-Haoyi


On Wed, Jul 24, 2013 at 9:35 AM, Jonathan Brandvein <jon.brandvein at gmail.com
> wrote:

> In the deprecated (removed in Python 3) compiler library, it was possible
> to construct a "Const" AST node. This node took in an arbitrary Python
> object, and got compiled to a LOAD_CONST opcode. This functionality is not
> available with the modern ast library. I wonder if there are any objections
> to adding it.
>
> Embedding objects in the AST can be handy. In a program transformation,
> you can avoid having to create code to define and assign to a new variable
> name. In code that is meant for exec or eval, you don't need to add the
> object to the global or local namespaces that you pass in.
>
> You also avoid the runtime overhead of a global namespace lookup, although
> your semantics are slightly different in that the object cannot be replaced
> at runtime. For a program transformation that introduces its own fixed
> objects that are not meant to be hot-swapped or monkey patched, this is a
> good tradeoff.
>
> I bring this up because I just ported a project from Python 2.4 to 3.3,
> and this was one feature where there was no good modern substitute
> available.
>
> The one drawback I can think of is that there is no general canonical
> source representation for an arbitrary constant. I will note that there are
> already ASTs that don't have a unique source representation: think of two
> ast.Name nodes that differ in their Store/Load context.
>
> Are there any limitations in CPython concerning what values can be placed
> in co_consts and accessed by LOAD_CONST?
>
>
> Jon
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130724/38cb746f/attachment-0001.html>