[DyrektorWykopu]

Kiedy (i czy w ogóle) w #python stosujecie foo(bar) zamiast bar.foo()?

[Budek24]

@DyrektorWykopu: To zależy czym jest i co ma robić foo i czym jest bar :)

[piotrb]

@DyrektorWykopu: Dopóki nie potrzebuję przechować stanu ( ͡° ͜ʖ ͡°).

[DyrektorWykopu]

@Budek24: No właśnie o to pytam - czym jest i co robi foo(), gdy używasz jej jako globalnej funkcji, zamiast metody klasy.

@piotrb: Nie chodzi mi o różnicę między foo(bar) i s.foo(bar), gdzie obiekt s przechowuje jakiś stan, tylko o różnicę w powodach implementacji np. len(str) i str.len(), gdzie funkcja nic nie musi przechowywać

[Pipcieo]

tylko o różnicę w powodach implementacji np. len(str) i str.len(), gdzie funkcja nic nie musi przechowywać

@DyrektorWykopu: chłopcze, wróc do podstaw

len(str) <==> str.__len__()

[DyrektorWykopu]

@Pipcieo: Po co ten protekcjonalny ton?

Z dokumentacji

object. len (self)
Called to implement the built-in function len(). Should return the length of the object, an integer >= 0.

I co teras?

[Pipcieo]

)

@DyrektorWykopu: gówno

>>> class JestesGlupi: __len__ = lambda _: 9**9

...

>>> len(JestesGlupi())

387420489

[l.....i]

@DyrektorWykopu: zlej tego typa. Wczoraj groził jakiemuś mirkowi, że nie znajdzie pracy w Django/Pythonie w Poznaniu, bo go zgłosił za "#usunkonto lamerze". Wieczorem też się pluł do kogoś pod tym tagiem. Od razu poleciał na czarną i sugeruję takie samo rozwiązanie :p

edit: no, w Twoim wpisie też jest w formie :D

[Budek24]

len(str) <==> str._len()

@Pipcieo: To nie jest prawda dla wbudowanych obiektów implementacji CPython. Długość jest po prostu odczytywania z pola struktury w języku C.

@DyrektorWykopu: Generalnie funkcje takie jak len i abs nie są wywoływane jako metody ('abd'.len()) , ponieważ są traktowane jako część modelu danych Pythona.

Dzięki specjalnej metodzie len_ możemy sprawić, że funkcja len będzie działać dla niestandardowych obiektów.

[Pipcieo]

@Budek24: mój post tłumaczył, że teza dysrektorWykopu

gdzie funkcja nic nie musi przechowywać

jest bzdurą i nie ma co na jej podstawie zadawac pytań.

To co się dzieje w CPython (a zwłaszcza optymalizacje) nie ma tutaj żadnego znaczenia, bo to szczegół implementacyjny w C, a jesteśmy na tagu #python a nie #c.

[DyrektorWykopu]

@Budek24: Staram się kierować zasadą, że zawsze istnieje jedna "właściwa" metoda napisania czegoś w pythonie. Więc jeśli mam na przykład ep = Episode(*args), to czy lepiej jest zrobić h = ep.simulate() czy h = simulate(ep). Niby różnica niewielka, ale zawsze lepiej rozumieć, dlaczego jedno jest lepsze od drugiego.

Tymczasem @Pipcieo twierdzi... właściwie nie rozumiem już za bardzo, co on twierdzi. Że nie mogę napisać funkcji, która jest stateless? Bo

[Pipcieo]

Niby różnica niewielka, ale zawsze lepiej rozumieć, dlaczego jedno jest lepsze od drugiego.

@DyrektorWykopu: różnica jest fundamentalna. pierwsze to programowanie obiektowe, drugie strukturalne. napisałem ci w pierwszym poście: WRÓC DO PODSTAW

Natomiast w konkretnym przykładzie z len() uświadomiłem ci, że to zły przykład, bo len to builtin który woła __len__ na instancji. Dla każdego innego (ale poprawnego przykładu) patrz paragraf wyżej.

[Pipcieo]

I jeszcze jedno, bo być może nie wiesz.

ep.simulate() == Episode.simulate(ep)

[DyrektorWykopu]

@Pipcieo: Ja nie wiem, co ty mi próbujesz udowodnić. Przecież to, co ty piszesz, nie odnosi się do tego, o co ja pytam. Chyba po prostu masz wrażenie, że coś ci rośnie, jak zwracasz się do innych w tonie wyższości. Trochę słabo, bo nawet czytać ze zrozumieniem nie potrafisz. Twój wkład w ten wątek został odnotowany. Teraz idź umacniać swoją męskość gdzieś indziej.

[Pipcieo]

co za tępa dzida

[dikamilo]

Staram się kierować zasadą, że zawsze istnieje jedna "właściwa" metoda napisania czegoś w pythonie. Więc jeśli mam na przykład ep = Episode(*args), to czy lepiej jest zrobić h = ep.simulate() czy h = simulate(ep). Niby różnica niewielka, ale zawsze lepiej rozumieć, dlaczego jedno jest lepsze od drugiego.

@DyrektorWykopu:

A jak się zachowa:

simulate(None)
simulate(1337)
simulate('no elo')

Dla mnie prawie zawsze jak coś nie jest wywoływane "z instancji obiektu" jako globalna metoda

[Budek24]

@DyrektorWykopu: W tym przykładzie ep.simulate(), bo jak rozumiem simulate jest ściśle powiązana z obiektem ep i nie ma sensu robić simulate na innych typach danych.

Poczytaj sobie o tym czym jest programowanie zorientowane obiektowo (OOP).

W Pythonie można pisać obiektowo, strukturalnie jak i funkcyjnie (mamy sporo zapożyczeń z Lispa jak i Haskella)

[DyrektorWykopu]

@dikamilo: A jak się zachowa len(None) i len(1337) i abs("dupa")? W concurrent.futures jest na przykład funkcja wait(), która odnosi się tylko do obiektów typu Future, a mimo to nie jest metodą klasy. Wg Twojej zasady wszystko zawsze powinno być metodą. Pasuje to chyba do javy (małą ją znam, dlatego chyba), ale jak widać python tej zasady się nie trzyma.

@Budek24: simulate() powiązane jest z klasą Episode na tej samej zasadzie,

[DyrektorWykopu]

W Pythonie można pisać obiektowo, strukturalnie jak i funkcyjnie (mamy sporo zapożyczeń z Lispa jak i Haskella)

@Budek24: I w myśl zasady, że zawsze istnieje właściwy sposób napisania czegoś w pythonie, coś z tego trzeba wybrać. Takie Django na przykład w większości kodu stosuje oop, ale już middleware są funkcjami.