udapi/udapi-python

python-demo.sh errors: "unexpected keyword argument 'filename'"

fractaldragonflies opened this issue · 4 comments

fractaldragonflies commented

Recently installed and can do udapy -h, but fails on python-demo. Do I have improper or corrupt install? Or is this present in other installations? Thanks!

$ ./python-demo.sh
Traceback (most recent call last):
File "/usr/local/bin/udapy", line 84, in
runner.execute()
File "/Users/johnmiller/udapi-python/udapi/core/run.py", line 133, in execute
blocks = _import_blocks(block_names, block_args)
File "/Users/johnmiller/udapi-python/udapi/core/run.py", line 103, in _import_blocks
new_block_instance = eval(command) # pylint: disable=eval-used
File "", line 1, in
File "/Users/johnmiller/udapi-python/udapi/block/read/conllu.py", line 52, in init
super().init(**kwargs)
File "/Users/johnmiller/udapi-python/udapi/core/basereader.py", line 17, in init
super().init(**kwargs)
TypeError: init() got an unexpected keyword argument 'filename'

martinpopel commented

Thank you very much for pointing this out. Your install is most probably OK. The demo was outdated, the parameter has been renamed from filename to files.
I've fixed the demo now.

BTW: If Udapi is installed correctly (e.g. with pip install), there is no need to set up $PATH and $PYTHONPATH as done in the demo.

fractaldragonflies commented
fractaldragonflies commented
martinpopel commented

https://github.com/fractaldragonflies/universal-dependencies

Well done. Thanks for sharing. I am happy Udapi is useful.

Just note that tree.get_sentence() returns the raw sentences as a Python string.
Thus count_tokens += len(tree.get_sentence()) is misleading - it computes the number of characters (including spaces), not tokens.
For computing (syntactic) words, use count_words += tree.descendants.
For computing tokens (possibly multiword), use count_words += tree.token_descendants.
The code could be rewritten as a Udapi block similar to util.Wc (so it can be combined with other blocks, e.g. util.Filter or applied to multiple documents/files), but if you like using Udapi as a library, it is also possible (it is not considered a hack) - it is perhaps better for the IPython notebook purposes.

I’m wondering if the current README.md for udapy needs updating as well? It still configures $PATH and $PYTHONPATH.

I think the current README.md is OK in this aspect. There are two ways of installing:

  • for users who don't want to edit the Udapi sources and contribute to Udapi (they can still write their own blocks and place them anywhere their Python can find them). Here no $PYTHONPATH editing is needed, just pip3 install --user --upgrade udapi.
  • for developers who like to have the sources in a git repo, so they can try different branches (or versions not published on PyPI yet) and contribute to Udapi. Here editing $PYTHONPATH is needed (or some alternative, e.g. pip3 install -e /path/to/udapi).

Not yet in my GitHub, I wrote a custom Block inheriting from udapi Block.
Named it .Custom so that udapy would recognize as user provided component.

There are two ways

  • name the module udapi.block.my.whatever, name the class Whatever, store it in udapi/block/my/whatever.py and call with udapy my.Whatever. Note that Python does not allow to have multiple directories with the same name in $PYTHONPATH, so the udapi/block/my/ location needs to be where the rest of Udapy is installed (the directory my can be a symlink).
  • name the module my.whatever, name the class Whatever, store it in xy/my/whatever.py and call with udapy .my.Whatever and make sure the xy directory is in your $PYTHONPATH. Note the initial dot in "udapy **.**my.Whatever". See #44.

To get udapy to recognize it, I had to install it via pip3.

Yes, in both the above-mentioned ways, your Python must be able to find your block. In the first way, you add my.whatever.py in udapi/block which is already in a location where Python sees it. In the second way, you edit $PYTHONPATH to include xy. And yes, an alternative to both is to install your module with pip3.