Unfortunately, I wrote pyparsing after working in Java for a number of years, and was convinced that camel case would be the preferred way to implement this API. PEP-8 compliance is a long-term goal for pyparsing, but will have a major impact on existing pyparsing applications. I think any efforts in this direction will require some tools to help applications to convert. But if you want to make an effort in this direction as a way to scope the size of this work, that would be very helpful. But actual release of any such code will be in pyparsing 3.0 at the earliest.

As for reorganizing the pyparsing code into sub-packages, I prefer to keep pyparsing as a single-module, to make it easy for dependent libraries and applications to include as an embedded module. This is currently how pyparsing is included in matplotlib and packaging modules.

See notes in new wiki page "PEP8 Planning"

On the subject of "reorganizing the pyparsing code into sub-packages": I would like to see this too.

The first step would be to move pyparsing.py to pyparsing/__init__.py; dependent libraries need not change, and the single-module is now a single-directory (so just as easy to embed). Then, __init__.py can be broken down into component modules at your leisure.

@ptmcg Here is some more interest in improving pyparsing mozilla/moz-sql-parser#58

Excellent - I will also post some general performance recommendations on the wiki.

Done - see https://github.com/pyparsing/pyparsing/wiki/Performance-Tips

Since the pep8 would rename many things and you want to keep the old names for legacy reasons around as I see (makes sense), why not just add this things ASAP and have a duplicated API? New applications depending on pyparsing can the already use the new API instead of being forced (as now) to use the old one.

That is an ambitious change, but it is very interesting that you propose a parallel API. I was not thinking of taking on all of Py2 drop, restructure code, AND PEP8 conversion in this one release, but a parallel API might make it palatable - as you say, it would preserve backward compat, but allow new apps to use more mainstream coding style.

I'll give this a look, thanks for the idea!