Przykład:
Mam ścieżkę:
path = pathlib.Path("usr/bin/etc/lib/1.tif")
Chciałbym takie pole wyesportować do stringa za pomocą
path.__str__()
Oraz posiadać na początku slash dla danego systemu operacyjnego
Czyli zamiast:
usr/bin/etc/lib/1.tif
mieć:
/usr/bin/etc/lib/1.tif
Czy za każdym razem powinienem dodać:
os.sep + path.__str__()
Czy jest to możliwe?
usr/bin/etc/lib/1.tif i bezwzględna /usr/bin/etc/lib/1.tif to nie są te same ścieżki. Czemu nie używasz tam ścieżki bezwzględnej?__ to średni pomysł. W tym przypadku raczej str(path)
@Shalom: Dlaczego używać i kiedy str() a kiedy __str__()?
Ścieżka jest względna względem tz. relative path i musi zostać umieszczona w pliku, który jest opisem metadanych na serwerze. W tym przypadku do programu, który to odczytuje ona jest ścieżka bezwzględną, ale już po wrzuceniu na serwer. Musi być tak w pliku.
No to skoro musi tak być, to tak będzie. Możesz chcieć się tylko upewnić, czy faktycznie musi i np. takie resolve Cię nie zadowoli.
A co do str kontra __str__ — moim zdaniem nie ma większej różnicy. Dokumentacja mówi wprost, że bardziej wysokopoziomowy str użyje tego niskopoziomowego __str__. To trochę tak, jakbyś zamiast pisać x < y pisał x.__lt__(y). Czytelność się trochę pogarsza, ale to w sumie tyle — a i sama różnica niezbyt duża, w mojej opinii.
Na jakie pytania sobie odpowiedzieć kiedy chciałbym używać __str__() lub str()? Czy w takim razie używanie __str__() w kodzie nie powinno się stosować?
Nie widzę sensu wywoływania dunderów w normalnym przypadku w ogóle. Może mieć to jakiś sens w nienormalnym, jak globalny str jest nadpisany (o ile może być, bo nie wiem czy w ogóle może).
@Marcin Marcin: str() jest trochę bardziej elegancki — i to tyle. Zatem raczej nie powinieneś używać __str__() jawnie, ale jak użyjesz, to też i tragedii nie będzie.
@alagner: bez znaczenia, str woła__str__(), to jest dokładnie to samo, tylko z „cukrem syntaktycznym”.