On 2019-01-10 14:22, g...@g...com wrote:
> W dniu czwartek, 10 stycznia 2019 14:02:42 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).
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().

>> 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.

>> 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.
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.
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 :(
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.
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:).
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).

AK