Błąd #4438
Rel writer nie nadaje się do użytku pytonowego
| Status: | Nowy | Start date: | 22 Nov 2012 | |
|---|---|---|---|---|
| Priority: | Normalny | Due date: | ||
| Assignee: | Łukasz B | % Done: | 0% | |
| Category: | - | |||
| Target version: | - |
Description
Relation writer z corpus2_whole ma w sygnaturze coś takiego:
void write(const std::vector< boost::shared_ptr<Relation> >& relations);
To jest opakowane w swig/relationwriter.i bez żadnego dodatkowego kodu, więc nie ma możliwości wywołania tego na własnej liście relacji (funkcja wymaga podania c++-owego wektora). W dodatku reader relacji niby zwraca taki wektor, ale jest on const, więc też nie można go zmienić.
const std::vector< boost::shared_ptr<Relation> >& relations()
Zasadnicze pytanie: czy coś w ogóle korzysta z tego writera?
Trzeba będzie rozważyć dwie opcje: albo zmienić tylko we wrapperze swigowym (.i), albo w ogóle zmienić to API. Pewnie to pierwsze będzie bezpieczniejsze.
History
#1 Updated by Łukasz B over 10 years ago
To było dawno pisane przeze mnie, żeby można było dodawać nowe relacje (anafory) do dokumentów i zapisywać je do osobnego pliku. W sumie spora część mojego projektu korzysta z tego writera. I da się to zrobić z poziomu pythona. Do metody 'write' podaję tuple obiektów corpus2.Relation, na których wywołuję '.rel_pt()'. Nie wiem czy to jest legalne i zgodne z jakąkolwiek konwencją rozwiązanie, ale jak najbardziej da się tego użyć z Pythona.
#2 Updated by Adam Radziszewski over 10 years ago
Jeśli SWIG jest w stanie sam opakować tuple pytonowe w std::vector, to super, mechanizm jest ok.
Niezbyt podoba mi się nazwa metody rel_pt(), bo nazwa w żaden sposób nie odzwierciedla tego, że tworzona jest kopia.
Ta metoda powinna nazywać się clone(), albo najlepiej clone_shared(), tak jak w libcorpus2/chunk.h czy libcorpus2/sentence.h
Czy oprócz tego jednego projektu korzystasz gdzieś z tego? Jeśli nie, to proponuję to zmienić, wygląda na to, że jeszcze istnieje taka możliwość.