Please make the parsetab.py files reproducible about ply HOT 11 CLOSED

It might not be a bad idea to use an ordered dict class. There was even a version of ply where I had to do this (it was relying on dict keys having a consistent order).

from ply.

Hi, ping? :)

from ply.

Dictionaries are used all over the place in yacc. Not sure I can easily fix this or not.

from ply.

@dabeaz Could you just do sorted(dct.items()) instead of dct.items()?

from ply.

Would such a change affect performance though? Should it be for the debugging implementation only, and not any optimized ones?

from ply.

@johnyf I think that would only be run when parsetab.py is being written, though, so it would be only for the first run.

from ply.

Suggest using yacc(write_tables=False) to disable the creation of the parsetab.py file entirely.

Background: The whole reason that parsetab.py file is there in the first place is that the first version of PLY was written on a 200Mhz PC and the parser table creation was slow. To make startup faster on subsequent runs, parsetab.py was written and used as a kind of cache. I'm not even sure it matters now. For one, machines are a LOT faster. Also, PLY switched over to a different, much faster, algorithm ages ago (generating the tables for C with some 353 states takes about 0.3s on my current machine).

Honestly, I've been thinking about ditching all of this parsetab.py/lextab.py business entirely in some future version.

from ply.

(Not all dicts would have to be changed, mind you...)

from ply.

In my experience with promela, the parsetab.py is useful and does accelerate runs. I would prefer that it remains available as functionality. Quantifying the difference would require collecting measurements from running a representative collection of large parsers.

from ply.

Ditching parsetab.py/lextab.py is not something I'm likely to do in the context of PLY. I have a more modern project in the works (a successor to PLY) that will ditch the generated files however.

from ply.

Hello, FWIW I switched the Debian packaging to the new release 1.0.0
https://github.com/viraptor/phply that seems to be the new one published on pypi

https://pypi.debian.net/phply
https://pypi.python.org/pypi/phply

So, I consider this issue "fixed" for my packaging needs

from ply.