W dniu czwartek, 10 stycznia 2019 15:47:22 UTC+1 użytkownik AK napisał:

> >>> No, można i tak.
> >>
> >> Ano mozna.
> >> Zwlaszcza, ze jest to zgodne ze z podstawowa logika i
> >> specyfika Pythona (metkowanie).
> >
> > A jaka jest "podstawowa logika i specyfika Pythona",
> > z której by ta zgodność wynikała?
>
> Metkowanie.
> 1. Obiekty w Pythonie sa wylacznie "metkowane".
> Kopiowane sa wylacznie prymitywy (int , float, bool i.. i chyba tyle).

Tzn. przekazywane przez referencję?

> 2. definicja funkcji to jest _statement_ wiec wszystko co podlega
> ewaluacji, jest _wlasnie wtedy_ ewaluowane.
> Stad wartosci domyslne sa ewaluowane w momencie wykonania
> _statementu_ def function().

A jakie są pozostałe "statementy"?

> >> Kwestia czy zle (przylaczam sie do twierdzenia ze jest to mylace,
> >> - choc wylacznie dla poczatkujacych), czy dobrze (przy rekurencji
> >> przydatne czesto) jest dyskusyjna.
> >
> > To może podaj kilka argumentów na rzecz takiego rozwiązania
> > (bo ja serio nie widzę żadnego)
>
> W rekurencji latwo zapamietac jakas "sciezke" wlasnie w takim
> parametrze.
>
> No ale przyklad z tej dyskusji.
>
> pierwsze = [2]
> def jest_pierwsza(liczba, pierwsze=pierwsze):
> erasto = int(sqrt(liczba) + 0.5)
> czy_pierwsza = all(liczba % pierwsza for pierwsza in pierwsze
> if pierwsza <= erasto)
> if czy_pierwsza: pierwsze.append(liczba)
> return czy_pierwsza
>
> Mozna zapisac tak:
>
> def jest_pierwsza(liczba, pierwsze=[2]):
> erasto = int(sqrt(liczba) + 0.5)
> czy_pierwsza = all(liczba % pierwsza for pierwsza in pierwsze
> if pierwsza <= erasto)
> if czy_pierwsza: pierwsze.append(liczba)
> return czy_pierwsza
>
> Po co tworzyc niepotrzebnie globala/statica jesli jest on potrzebny
> tylko wewnetrznie?
> Jak wiadomo Python nie posiada takiej konstrukcji zmiennych/obiektow
> statycznych funkcji w takim sensie jak C
>
> int fun()
> {
> static int = 3;
> }
>
> wiec w ten sposob tworzy sie w Pythonie wlasnie zmienne statyczne
> nie zasmiecajac wyzszego namespace.

Można też użyć do tego celu "domknięcia", albo klasy.
Przekazanie parametru rekurencyjnie do funkcji to nic trudnego

> >> PS: Innym podejsciam jest zastosowanie czegos w rodzaju:
> >>
> >> def f(x=on_the_call(None)):
> >> return x
> >
> > Czyli mamy co najmniej dwa złe idiomy zamiast jednego dobrego rozwiązania.
>
> Dlaczego zle ?
> Nie widze w nich nic zlego.

Sam powiedziałeś, że "bywa mylące".
Ja uważam, że jest mylące z dobrych powodów.

> Zwlaszcza w stosunku do expr w takim Lisp gdzie nawet priorytet
> opeatorow poszedl do kosza wiec trzeba go wymuszac odpowiednia
> kolejnoscia ewaluacji i/lub nawiasami (a nawet trzeba wymuszac/okreslac
> tymiz lewo-prawo-lacznosc operatorow).
> Np: (* A (* B (* C D))) to co innego niz (* (* (* C D) B) A)
> Przecie to nieskonczone zrodlo pomylek.

?
Jakich pomyłek?
W każdym języku f(x, f(y, f(z, w))) to raczej coś innego niż
f(f(f(z, w), y, x).
I to nie jest "wymuszanie nawiasami lewo-prawo-łączności operatorów",
bo w Lispie syntaktyczine w ogóle nie ma czegoś takiego.
Akurat operator mnożenia jest (semantycznie) łączny i przemienny,
toteż nie ma znaczenia, czy napiszesz tak, czy inaczej.
Możesz też napisać (* A B C D) albo (* C D B A).

> PS: Tylko mi nie probuj mowic, ze jest inaczej bo drzewiej
> pisywalem (fakt ze rzadko, nie umialem sie przekonac:) w AutoLispie
> makra do AutoCADa "cus tam" liczace i... to dla numeryka byl
> istny koszmar :(

Co ja mam Ci próbować wmówić?
Jak czegoś nie lubisz, to to Twoja sprawa.

> W porzadnych jezykach programowania kolejnosc obliczania expr. byla
> zawsze od lewa do prawa, a priorytet operatorow jest scisle okreslony
> i dla arytmetycznych zgodny z normalna matematyka.

Lepiej zamiast "normalna matematyka" powiedzieć
"matematyka, której mnie uczono".

> Oczywiscie C/C++ to popsul bo w nim stwierdzono (z wydumanych wzgledow
> wydajnosciowych oczywscie:) ze kolejnosc ewaluacji czesci wyrazen jest
> .. dowolna co rowniez jest zrodlem niekiedy koszmarow (gdy
> funckcje maja efekty uboczne - a miewaja czesciej niz sie wydaje:).

W "normalnej matematyce" funkcje nie mają efektów ubocznych.

> PS: Nawiasy nie pomoga. Nawiasy w C/C++ wymuszaja priorytety, ale nie
> kolejnosc ewaluacji wyrazen.
> Np takie cus w Algolu, Pascalu, Fortranie, PL/I, Javie, C# czy innym
> Pythonie:
> double y = 3;
> double fun(double x)
> {
> y += x;
> return y;
> }
> z = 2 * fun(3) + fun(7);
> byloby jednoznaczne (wynik 25), ale juz w C/C++ moze to byc
> albo 25 albo 36 (zaleznie od kierunku wiatru, kompilatora,
> gestosci Slonca, % w nalewce Szwagra itp).

No i bardzo dobrze.
Przynajmniej zniechęca ludzi do pisania takich programów.