On 2019-01-11 19:14, g...@g...com wrote:
> W dniu czwartek, 10 stycznia 2019 15:47:22 UTC+1 użytkownik AK napisał:
>
>> Metkowanie.
>> 1. Obiekty w Pythonie sa wylacznie "metkowane".
>> Kopiowane sa wylacznie prymitywy (int , float, bool i.. i chyba tyle).
>
> Tzn. przekazywane przez referencję?

Nie. To jednak nie jest to samo co referencja w C++ czy innej
Javie.

>
>> 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"?

Takie jak w manualu.

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

Po co ?
PS: Owszem, Przy wiekszej ilosci danych/atrybutow uzywa sie w Py klasy,
named tuple, slownika, domkniec itp itp.

> Przekazanie parametru rekurencyjnie do funkcji to nic trudnego

Po co przekazywac "z gory" jesli mozna to samo uzyskac
w lokalnym scope ? No po co ? Bo?

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

No jesli sie nie czyta wpierw nic o jezyku/manuali
to wszytsko bywa mylace :)
Poza tym to bardzo standardowe idiomy.
Wszedzie w Py spotykane.

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

Tyle ze przy mnozeniu jest to to samo.

Chodzi o to ze trzeba ciagle pilnowac priorytetow operatorow
(czy kolejnisci) przez odpowednie konstrukcje - czyli na bakier
normalnej metematyce. Notacja Lisp akurat wyrazeniom arytmetycznym
wyraznie szkodzi i nie ma co tego tlumaczyc "elegancja" czy
"czystoscia" paradygmatow jezyka. To syf w uzyciu i tyle!

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

Ma znaczenie bo w jezykach programowania _istnieja efekty
uboczne_ i kolejnosc ewaluacji (od lewa do prawa) MA
znaczenie.

> Możesz też napisać (* A B C D) albo (* C D B A).

Moge. Tylko czy to wyglada na zapis matematyczny?
Toz to zwykla lista :)

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

Nie lubie dlatego, ze nie lubie.
Nie lubie, bo sprawia tak wiele niedogodnosci,
ze odciaga od domeny na rzecz młotka.

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

Mnie uczono normalnej a nie (pre-post-s)fiksowanej.

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

Programowanie "realne" to nie matematyka i efekty uboczne
sa "immanentna czescia" nie tylko C++.
W "moich czasach" nie mowilo sie "funkcje" ale "procedury".
Nazwe "funkcje" (intencjonalnie) zostawialo sie matematyce.
Algol/Simula"

integer procedure A()
begin
end

real procedure A()
begin
end

procedure C()
begin
end

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

Masz Ty pojecie o produkcyjnym rzemiosle?
Jesli mozna, to ludzie pisza zle i tyle.
Zaden jezyk przed tym nie uchroni, lecz powinien przynajmniej
zadbac, aby wyniki byly powtarzalne i nie zalezaly od kierunku wiatru.

Jezyki takie jak Algolu/Simula, Pascalu, Modula2, Fortran, PL/I, Java,
Python, C#, VB o to zadbaly. C++ nie.

AK