Handy functions

[bugaevc]

An implementation of a few ideas found in Parsec:

• parser.should_fail() succeeds (consuming no input) if parser fails
  • parser << other.should_fail() — this is how you do Parsec's notFollowedBy
  • (other.should_fail() >> parser).many() for Parsec's manyTill
• seq(*parsers, f=...) allows for easier post-processing, compare before and after
• parser.sep_by(sep) is roughly equivalent to parser.times(1) + (sep >> parser).many(). It can however handle zero-times case and has min and max keyword-only arguments.
  • Python-style tuple literals would be lparen >> (expr.sep_by(comma, min=2) | expr.times(1) << comma | success([])) << rparen

[EricSL]

Not up to me, but I'd prefer f be named seq_fn for consistency with map/bind.

[bugaevc]

Well, the difference is that you almost certainly wouldn't pass arguments to map/bind by name (and most likely you wouldn't even know what they're called), whereas in this case it's keyword-only, so I wanted to use a shorter name. I do not insist though. Let's wait for @jneen to decide.

[spookylukey]

I think that this extra keyword parameter would work better as a separate method, perhaps named combine. I can see situations where it would be useful outside of the context of seq, such as after many, or if you want to reuse a parser defined elsewhere, and it would be cleaner this way I think.

[bugaevc]

I may not be following; how would it be different from .map()?

And my present self is not that convinced with "compare before and after" example from my 2.5-year-younger self, so maybe we don't need that feature at all.

[spookylukey]

I've added a PR for this feature here - python-parsy#3 - which happens to include docs that answer your question. Let me know what you think.

[bugaevc]

Oh. Yes, that looks good and is indeed cleaner. 👍

How would you use it with .many() though? (you don't know the arg count; you use .times() when you do know)

[spookylukey]

You're right, times() would be a better example, although occasionally you might use manyy() followed by some constructor functions that take an arbitrary number of arguments via*args.

[bugaevc]

float('inf') is math.inf in modern Python; at least this doc should be updated, not sure about the code - do we keep compatibility with earlier Python 3.x versions?

[spookylukey]

Looks like math.inf was only added in 3.5, I wouldn't break 3.3 and 3.4 compat for this. Although we could pull it out as a constant at module level for a performance improvement.

[spookylukey]

This introduces tons of flake8 errors/warnings, plus can give static analysers/"goto definition" a harder time for anyone working on the code. I don't think it is worth it.