To be honest I have not studied panflute in great details (started my own project before panflute 1.0 was released when my use case was not covered yet).
I guess that there is a lot of common ground here but with different elements of style, so if you are a happy user of panflute, i don't avise you to change.
I'd say that panflute probably feels higher-level (and maybe terser for the common use cases ?) and pandoc (Python) more minimalistic and slightly more Haskell-ish.

Some misc. things I can think of:

  - Pandoc (python) adapts the AST model which is used to the pandoc version discovered on your system (or to the one you specify),
    so you will probably only need a single version of it, even if you deal with several pandoc binaries.
 
  - Our hierarchy of classes is automatically generated (from the registered Haskell type info). So if you know the original data model, then you're already covered.
If you don't know it, it is documented but you can also discover it interactively in the Python interpreter (which I like very much ❤️):

>>> from pandoc.types import *
>>> Pandoc
Pandoc(Meta, [Block])
>>> Block
Block = Plain([Inline])
      | Para([Inline])
      | LineBlock([[Inline]])
     ...
      | Div(Attr, [Block])
      | Null()
>>> Para
Para([Inline])
>>> Inline
Inline = Str(String)
       | Emph([Inline])
       | Strong([Inline])
       | Strikeout([Inline])
       ...
       | Note([Block])
       | Span(Attr, [Inline])

    I don't know how the panflute type hierarchy is generated (manually ?) and exactly what the trade-offs are in each case.
    For example we don't use named arguments for the pandoc element arguments since there is no such thing in Haskell.
    There are differences such as Para(Str('eggs')) for panflute but Para([Str('eggs')]) for pandoc (Python) (to compare with the Haskell type info)
    The panflute types have also more methods while ours are rather "dumb" (mere algebraic data types) which is a matter of taste I guess (?).
    But overall the (AST) type hierarchy feels very similar.

  - I think that apart from the AST, the core of panflute is probably run_filter, while our core tool is pandoc.iter, a (top-down, document-order) iterator.

  - The dynamic type checking of panflute is very nice 👍. I don't have the equivalent (yet) and that can honestly sometimes be a pain.

If you are a regular panflute user and can have a quick look our docs, especially the examples of code, I'd appreciate some feedback about what you like and don't like!

Cheers,

Sébastien

Le samedi 4 décembre 2021 à 16:30:46 UTC+1, Joseph a écrit :
Can you speak to what the advantages of this would be over panflute?

http://scorreia.com/software/panflute/

On 21-12-04 09:43, Sébastien Boisgérault wrote:
> AFAICT filters are document AST to AST transformations. In this Python library, docs (Pandoc instances) represent this AST, so a typical AST (in-place) transform would be:

--
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/1e952a20-a77f-4987-9e7f-bac963ba4385n%40googlegroups.com.