Using the LALR file cache on Python 2.7 fails with "unbound method exists() must be called with FS instance as first argument (got str instance instead)"
See original GitHub issueI’m using Lark for epycc https://github.com/antoniotejada/epycc on Python 2.7 and I found that when using the LALR with cache=True:
parser = lark.Lark.open(grammar_filepath, keep_all_tokens="True",
lexer="standard", parser="lalr", cache=True)
fails with
Exception has occurred: TypeError
unbound method exists() must be called with FS instance as first argument (got str instance instead)
File "C:\Python27\Lib\site-packages\lark\lark.py", line 276, in __init__
if FS.exists(cache_fn):
File "C:\Python27\Lib\site-packages\lark\lark.py", line 501, in open
return cls(f, **options)
...
The problem is in utils.FS that doesn’t declare “exists” as @staticmethod the same way it’s done for “open”
An easy workaround is:
setattr(lark.utils.FS, 'exists', staticmethod(os.path.exists))
parser = lark.Lark.open(grammar_filepath, keep_all_tokens="True",
lexer="standard", parser="lalr", cache=True)
Issue Analytics
- State:
- Created 2 years ago
- Comments:8 (4 by maintainers)
Top Results From Across the Web
unbound method f() must be called with fibo_ instance as first ...
An unbound method is, of course, one that is not attached to an instance. ... f() must be called with C instance as...
Read more >Apache Beam Programming Guide
The Beam Programming Guide is intended for Beam users who want to use the Beam SDKs to create data processing pipelines. It provides...
Read more >2007-December.txt - Python mailing list
I need to get the username (The part BEFORE the @ sign) out of the > > address so that I can use...
Read more >unbound method f() must be called with fibo_ instance as first ...
PYTHON : unbound method f() must be called with fibo_ instance as first argument ( got classobj instance instead ) [ Gift :...
Read more >Guile Reference Manual - GNU.org
2.5.1 Using Modules. Guile comes with a lot of useful modules, for example for string processing or command line parsing. Additionally, there exist...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
That is reason enough. Otherwise, you would probably be using pycparser
Also note that you could alternatively add it as a requirement for the suffix to have the next character not be alphanumeric.
Also, you are the third person in the last few days to come across that issue. I think I am going to provide a PR.
(
return
as identifier for a call vsreturn
as a statement is something that could also be fixed by priorities. Also, adding a negative look ahead will certainly be faster than whatever else you can do in pure python, but might create large problems with the rest of lark.)Edit: The suffix problem is solvable by just moving the longest option first. Use
INT_SIZE_SUFFIX: "ll" | "LL" |"l" | "L"
instead.Thanks for the catch. We’ll merge the fix soon.
Just curious, in what context are you using Lark with Python 2.7?
I ask because we are planning to drop support for Python 2 soon.