Wpis z mikrobloga

@mcnight95: w moim przypadku gdzie jest filter to nie zadziała, bo len() nie działa na lazy. A w przypadku list comprahension nie lubię podawania tego a, bo mogę tam podać cokolwiek i będzie działać dokładnie w ten sam sposób, co sprawia, że mam szum, który utrudnia czytanie kodu
  • Odpowiedz
@mcnight95: wszystko zależy od gustu. Z mojej strony len(filter jest lepszy, ale python strasznie obrzydza pisanie w taki sposób jednocześnie nie dając dobrej alternatywy, przez co często muszę się zastanawiać jak napisać dany kod najładniej. Porównaj sobie to do scalowego n.count(_ < 0), zapis jest prosty, czytelny i nie da się zrobić tego lepiej
  • Odpowiedz
@Saly: Słabe jest na pewno to, że len nie działa na lazy, nie wiem w sumie czemu zostało to tak zrobione, skoro np sum już na lazy działa ¯\_(ツ)_/¯ Natomiast python nie jest typowo funkcyjnym językiem mimo posiadania pewnych cech takowego, a kierunek jego rozwoju raczej nie idzie w stronę bardziej funkcyjnego (jak np wypchnięcie reduce z globals do functools).
  • Odpowiedz
Słabe jest na pewno to, że len nie działa na lazy, nie wiem w sumie czemu zostało to tak zrobione, skoro np sum już na lazy działa ¯_(ツ)_/¯


@mcnight95: pewnie dlatego, że użytkownicy len nie spodziewają się "zużycia" lazy, a jest to konieczne. Jak zawołasz sum to zakładasz, że trzeba się po wszystkim przeiterować, przy len czasami tak jest a czasami tak nie jest

Natomiast python nie jest typowo funkcyjnym
  • Odpowiedz