@Kiro: masz rację, pogubiłem się w wątku - all jest ok, wygrywasz batonik ;) @Sargon_Ankro: w Pythonie łatwo jest napisać coś poprawnie, pisząc w C/C++ musisz zwracać uwagę na takie "niuanse", bo z nich później wykluwają się exploity :P
wyobraziłem sobię rozmowę kwalifikacyjną na juniora, na której jakiś kretyn się przyczepia "hurr durr czemu return fals" i zaraz wyrzuciłem ten obraz z głowy jako zbyt odrealniony. A wykładowcy się o takie coś potrafią przyczepić?
@LOLWTF: To jest poprawne, ale nawiasy [] je psują - to jest coś co wydawało mi się że @Kiro zrobił, ale nie zrobił :-) Przetwarzasz całą listę przez list comprehension.
Jak skończysz zbyt szybko to pan doktor ma dla ciebie zbyt dużo czasu, niektórzy lubią na siłę pokazać że się mylisz :p
@Kiro: a w prawdziwym świecie jest zupełnie odwrotnie. Czasu masz mało i czasem musisz powiedzieć "#!$%@?, robimy żeby jakoś działało, później się poprawi xDD"
W pytaniu nie było mowy o zwróceniu None w przeciwnym wypadku
Zarówno z akademickiego jak i praktycznego punktu widzenia, wszystko co nie jest TRUE jest poprawnym wynikiem tej funkcji, gdy przynajmniej jeden element przekazanej listy nie jest parzysty. Dlatego, faktycznie gdyby ktoś akademicko-czepialski musiał się do czegoś przyczepić to przyczepiłby się do if, a nie do zwróconego FALSE ( ͡°͜ʖ͡°)
w Pythonie łatwo jest napisać coś poprawnie, pisząc w C/C++ musisz zwracać uwagę na takie "niuanse", bo z nich później wykluwają się exploity :P
@co_to_sie_stanelo: tak, ale to zalezy od sytuacji. Nikt nigdy nie przewidzi wszystkiego, a im program większy, tym bardziej rośnie prawdopodobieńswo wystąpienia gdzieś problemu, nie zależnie od języka.
@LOLWTF: all przyjmuje jeden argument: coś po czym można iterować. To co dostaje w rozwiązaniu wyżej to generator expression - przewaga nad list comprehension jest oczywista.
@Pipcieo: Tylko w tym przypadku funkcja nie zwraca (jawnie) żadnej wartości, więc o ile faktycznie masz rację co do interpretacji pytania, to myślę że moje rozwiązanie też dałbym radę obronić. A gdybyśmy rozważyli to tylko na poziomie pseudokodu to już w ogóle :p
#naukaprogramowania #python
@Sargon_Ankro: w Pythonie łatwo jest napisać coś poprawnie, pisząc w C/C++ musisz zwracać uwagę na takie "niuanse", bo z nich później wykluwają się exploity :P
wyobraziłem sobię rozmowę kwalifikacyjną na juniora, na której jakiś kretyn się przyczepia "hurr durr czemu return fals" i zaraz wyrzuciłem ten obraz z głowy jako zbyt odrealniony. A wykładowcy się o takie coś potrafią przyczepić?
@Pipcieo: A z czego to wywnioskowałeś? :>
@LOLWTF: Jak skończysz zbyt szybko to pan doktor ma dla ciebie zbyt dużo czasu, niektórzy lubią na siłę pokazać że się mylisz :p
all()
trzeba wstawić jakiegoś iteratora, teraz się okazuje, że przyjmuje argsy xD@Kiro: a w prawdziwym świecie jest zupełnie odwrotnie. Czasu masz mało i czasem musisz powiedzieć "#!$%@?, robimy żeby jakoś działało, później się poprawi xDD"
Zarówno z akademickiego jak i praktycznego punktu widzenia, wszystko co nie jest TRUE jest poprawnym wynikiem tej funkcji, gdy przynajmniej jeden element przekazanej listy nie jest parzysty. Dlatego, faktycznie gdyby ktoś akademicko-czepialski musiał się do czegoś przyczepić to przyczepiłby się do
if
, a nie do zwróconego FALSE ( ͡° ͜ʖ ͡°)@co_to_sie_stanelo: tak, ale to zalezy od sytuacji. Nikt nigdy nie przewidzi wszystkiego, a im program większy, tym bardziej rośnie prawdopodobieńswo wystąpienia gdzieś problemu, nie zależnie od języka.
def wolaj():print "wolajo";return False
print all(wolaj() for i in range(10))
all
przyjmuje jeden argument: coś po czym można iterować. To co dostaje w rozwiązaniu wyżej to generator expression - przewaga nad list comprehension jest oczywista.var nazwa = arr=>arr.every(a=>!(a%2))
let nazwa = arr=>arr.some(a=>a===null)
None in arr