On Jan 18, 9:53 am, Krzysiek Kowaliczek
<k...@g...com> wrote:

> > No i super. Przynajmniej mam pełną kontrolę nad tym, jak ten string
> > wygląda. Świetnie się to sprawdza przy debugowaniu!
> > Python tak nie pomaga.
>
> Jako, że mam z tym styczność na co dzień, taka pomoc jest raczej
> mizerna. Mogę sobie wyobrazić dodatkową funkcję CHandleToString. I w
> czym to jest gorsze od jawnej postaci?. BTW. u nas wskaźniki C++
> kodowane są w postaci adres obiektu + adres na id typu, a nie wskaźnik
> + najczęściej długa nazwa typu, ponieważ tak jest wydajniej.

Wydajniej? Ale kogo to obchodzi? Cokolwiek byś nie zrobił w Pythonie w
celu poprawienia wydajności, będzie to przypominać montowanie
aerodynamicznych osłon na koła w ciągniku rolniczym.
Python (Tcl, itd.) nie służy do pisania wydajnych programów.
Może co najwyżej posłużyć do pisania niewydajnych kontrolerów do
wydajnych komponentów napisanych w odpowiednich do tego językach, ale
tu zabawy ze wskaźnikami nic nie wnoszą.

Już napisałem, że pomoc w przypadku tego stringa polega na możliwości
jego bezpośredniego wypisania w debugerze. Drugi wskaźnik na id typu
jest oczywiście poprawny technicznie, ale nie aż tak bezpośrednio
użyteczny. Zwłaszcza w debugerze.

> >https://www.google.com/search?q=Python+ctypes+64+bu
g
>
> Ale co mnie to interesuje jako użytkownika docelowego?

Nic. Po prostu Twój program, który działał na platformie 32 bit nie
będzie działał na 64 bit. Wywali się z hukiem a Ty będziesz obwiniał
autora jakiejś biblioteki, który nie popełnił żadnego błędu. Jeżeli
ten program był ważny, to zostaniesz w ciemnej d*pie razem ze swoim
nowym komputerem i niedziałającym programem i pretensjami do
niewinnych ludzi. Poza tym, jako "użytkownik docelowy", nie zauważysz
różnicy. :-)

> Ja zacząłem
> używać Pythona między innymi ze względu na dużą ilość bibliotek, co
> jest jego największą zaletą.

Przecież temu nie zaprzeczam. Nawet ten fakt sam podkreśliłem na
początku.
Jeżeli szukasz bibliotek, to Python je ma.
Natomiast jeśli szukasz języka do zagnieżdżenia i do oskryptowania
jakiegoś innego programu (np. gry, edytora graficznego, analizatora
poprawności, itd.), to fakt posiadania miliona bibliotek jest
nieistotny. Raczej przeciwnie - będziesz kombinował jak ograniczyć
zdolność interpretera choćby ze względu na bezpieczeństwo (sandbox) -
i tu Tcl kładzie Pythona na łopatki ze swoją koncepcją bezpiecznego
interprera, w który sami decydujemy, jakie polecenia są dostępne a
jakie nie, oraz z koncepcją łączenia interpreterów w układy master-
slave:

http://www.tcl.tk/man/tcl8.4/TclLib/CrtSlave.htm

Dla mnie *to* jest właśnie dobrze zrobiony interpreter. Szkoda, że te
pomysły zniknęły.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com