Configs to control the behavior.

[odashi]

It is worth to provide some mechanism to specify particular behaviors by users, such as:

• Specifying commands for particular operators (e.g., definition is usually represented as =, :=, \equiv, \triangleq, {\rm def} over =, or \leftarrow).
• Auto-converting math symbols.
• Appearances of control flow, or long equations.

Currently, with_latex decorator have an optional flag for math symbols, and I am suggesting to add similar ones for other options (#15). This way finally introduces a bunch of particular flags. So we need more sophisticated way to control these behavior.

[odashi]

Maybe it could be a choice to provide a global function latexify.set_config() to modify the default behavior:

import latexify
latexify.set_config(...)  # Calls it before any @with_latex decorators.

@with_latex
def foobar(...):
  ...

[1MLightyears]

class LatexifyVisitor(ast.NodeVisitor):
# define static variables here like
  math_symbol = True
  equal_form = r"\triangleq"

# change __init__ into
  def __init__(self, **kwargs):
    # config part
    for k in kwargs.keys():
      if k in dir(LatexifyVisitor):
        setattr(LatexifyVisitor,k,kwargs[k])
      else:
        # deal wrong config setting here
    ...

Will allow all instances of LatexifyVisitor keep the same config.

[odashi]

For this particular implementation, it looks somewhat dangerous because...

• object method (__init__) globally changes the class attributes.
• dir() returns every visible symbol of all super classes.
• kwargs drops much stuff for self-documenting -- using it brings difficulty for further maintenance.

I am thinking of separating configs from the visitor completely rather than directly implementing them into the class.

[1MLightyears]

Well...it isn't a strict implementation, I just want to show the logic. Of course there are many ways to strengthen its security, like

class LatexifyVisitor(ast.NodeVisitor):
  math_symbol = True
  equal_form = r"\triangleq"

  config_list=['math_symbol',
               'equal_form'
               # more could be added here in future
               ]

and change dir(LatexifyVisitor) into config_list, or
simply change

if k in dir(LatexifyVisitor):

into

if not callable(getattr(LatexifyVisitor,k,lambda:1))# or any callable dummy function

will guarantee k is a variable defined in LatexifyVisitor.
I'm just voting for implementing config inside LatexifyVisitor, but if you finally decide to have it outside, I'm also glad to see it. A config working is better than none.
As for documentations, it is true documenting things like kwargs takes a lot of time and energy. But since latexify is so welcomed and has earned 800+ stars so far, making it more easy to use would make latexify a better tool. All we need to do at present is to add an example at the Jupyter notebook page-I think that is a tutorial good and simple enough for new users.

[odashi]

Well, the essential point I am thinking of is these flags should not be class attributes since it would be changed every time we invoked __init__. And introspection is basically the final choice of implementation which is chosen only when there are no easier solutions.

The first intent of this issue is how to avoid specifying a bunch of flags to @with_latex for user-default flags. Your solution can resolve it by specifying a particular flag to only the first decoration, but it will also introduce any kind of confusion due to a stateful behavior of the decorator.

it isn't a strict implementation, I just want to show the logic.

I could think so, but couldn't guess which aspect is actually pointed. That's why I said "for this particular implementation..."

not callable(getattr(LatexifyVisitor,k,lambda:1)) will guarantee k is a variable defined in LatexifyVisitor.

Unfortunately no, it still returns many ruins from super classes. Of course we can also take any hacks to avoid them, but this is unneeded burden we have to take here.

[1MLightyears]

It seems I have misunderstood your requirements of the config. I'm not experienced in designing configs and thus haven't thought that far.
I would not try to implement the config part in #15 and would return the discussion after another config logic be come up with.

[odashi]

This issue is taken by #66 , close for now.