Newsgroup: it.comp.programmare
Titolo: [Python] indentazione, problema pratico

Dietro consiglio di Alex Martelli, ho installato il Python e mi sono
scaricato il manuale in vrsione PDF Acrobat "Diving into Python" o un titolo
simile, ma il punto non e' questo.
Il problema che ho avuto, e qui non gioiscano coloro che giudicano un
linguaggio solo per queste inezie, e' stato al momento di fare un semplice
copy-paste a partire dal documento PDF per riportare sull'IDE del Python del
codice esempio.
Ebbene, non so se il problema sa nella gestione della clipboard di PDF, ma
il paste ha perso tutte le informazioni di indentazione che c'erano ne
codice originale.
In sostanza, quando si va a fare il paste sul file dell'IDE del Python, si
ottengono tutte righe di programma che sono allineate a sinistra, perdendo
tutta la spaziazione originale.
Cio' che mi irrita e' che non e' possibile riallineare il codice come
nell'originale senza guardare come e' fatto il codice originale stesso.
Qua non si tratta, come era stato detto, di tools che attraverso la rete o
altro, fanno perdere le informazioni di indentazione, qua si e' trattato di
un semplice copy-paste a partire da un documento PDF, con conseguente
ambiguita' nel sorgente destinatario.
Ribadisco che non sto parlando della bonta' o meno di un linguaggio, voglio
solo cercare di parlare e di risolvere di un problema pratico che
stranamente non avevo mai letto qua in precedenza.
Bye
Maurus
--
Maurus

 stranamente non avevo mai letto qua in precedenza.
E' da settimane che lo dico!!! Ma perdono i miscredenti che non vogliono 
vedere ciň che č.
-- 
Luc.

 ambiguita' nel sorgente destinatario.
Ti stai lamentando di qualcosa o stai cercando una soluzione al problema ?
--------------------------------
Inviato via 
http://usenet.libero.it

 codice originale.
È vero, ma questo porblema (che non è presente in tutti i pdf) lo si 
osserva anche con altri caratteri. Ad esempio non riesco spesso a copiare i 
caratteri non US-Ascii e i " o ' vengono "pasticciati". Inoltre in un paio 
di altri pdf ho avuto diversi problemi a copiare anche le graffe, in 
particolare uno era un esempio piuttosto lungo in C, ci ho messo un sacco 
di tempo a riportarlo a posto considerando che si è mangiato graffe, spazi, 
apostrofi, virgolette e #.

vedere ciň che č.
a me succedeva anche con Thinking in Java su PDF...quindi č un
problema del PDF non del Python
--
Rhymes (
rhymes_...@myself.com
)
http://www26.brinkster.com/rhymes
http://bw-crema.blogspot.com


Entrambe le cose.
Immagina di fare un copy da Acrobat, in cui vi e' un file di esempio in
Python di centinaia di righe, e poi il tuo paste sull'Ide del Python, non ti
senti un pochino irritato dal fatto di dover ricostruire a mano tutta la
spaziatura originale per poter dare il run allo script senza errori?
Comunque gia' da altri ho saputo che non tutti gli Acrobat hanno questo
"baco", ma e' pur vero che ci sono i pro e i contro per l'indentatura del
Python.
I "pro" gia' li conoscevo, oggi ho conosciuto un "contro".
Maurus

 I "pro" gia' li conoscevo, oggi ho conosciuto un "contro".
Non dell'indendatura di Python: del tuo modo di scrivere codice.
E' ben diverso.


 problema non e' di Python, 
Il problema è di Python nella misura in cui esso non usa delimitatori.
Ciao e spero di non avere attizzato flames!
Fed.

 Il problema è di Python nella misura in cui esso non usa delimitatori.
Niente affatto.



Semmai del mio modo di fare copia-incolla.
Le alternative che mi hai dato, dimostrano che questo problema rimane
comunque fastidioso.
Maurus


Oddio, non dirmi che pensi veramente quello che hai scritto.
So bene che Python vuole le indentazioni per delimitare i blocchi di
istruzioni come in C/C++ si fa usando le parentesi graffe, ma non stavamo
parlando di questo.
Dai su non sminuire gli altri solo perche' stanno scrivendo cose che tu non
approvi.
Maurus

 codice esempio.
Maurus, credo saprai che il PDF è praticamente realizzato comprimendo
flussi postscript tramite algoritmi simili allo ZIP (c'è altro
overhead, ma è poca cosa). Fare il cut&paste da un PDF non è proprio
l'operazione più naturale che ci sia (immagina, il driver pdf estrae i
flussi compressi, questi vengono ritrasformati in postscript ed a
questo punto un driver postscript ce li stampa a video, una sorta di
miracolo, e noi pretendiamo pure di fare il cut&paste di quello che
vediamo ;-) , quando ci si riesce c'è solo da ringraziare ed alcune
volte è semplicemente ridicolo il solo pensarci, come ad esempio
quando il pdf è generato a partire da bitmap rappresentanti testo,
vallo a spiegare al management che è praticamente impossibile
(qualcuno potrebbe obiettare, beata incoscienza, che esistono gli
OCR).
--
ale
www.sen.it

 ale
Ciao Ale,
grazie per la precisazione.
Sapevo qualcosa a riguardo avendo lavorato su un'applicazione che (molto
alla lontana) voleva fare qualcosa di simile ad Acrobat: dopo previa
installazione di un driver di stampante virtuale, essa doveva "catturare" un
documento di non importa quale applicazione a partire dal suo EMF, e
trasformarlo in un formato proprietario per essere memorizzato su un server
ed essere ripresentato a video su un client che non aveva installata la
applicazione dal quale il file originario proveniva.
In sostanza si trasformavano i comandi EMF, per compattarli in un altro
formato e salvati, per poi emulare l'EMF originario ed eseguirne i comandi.
Ovviamente i problemi principali li avevamo quando dovevamo catturare un
file pdf.
Ad esempio sul client che non aveva Acrobat installato, si doveva eseguire
l'EMF trasformato, utilizzando le fonts di Windows che meglio emulavano le
fonts Acrobat del documento.
Il nostro cut&paste poteva essere testuale-unicode, EMF, WMF, bitmap o
tabellare.
Da un cut&paste testuale (non di bitmap) comunque, riuscivamo a preservare
gli spazi!
Maurus

 ambiguita' nel sorgente destinatario.
normalissimo. Copiando gli esempi da "Windows 2000 Native API" si 
passava sempre quella buona mezzora ad eliminare le intestazioni/pie' 
di pagina insinuatesi nel codice. E' un problema del PDF. E' un formato 
ancora troppo grafico. Molto più testuale del PS, ma evidentemente non 
abbastanza. Per questo assieme agli e-book in genere c'è uno zippone 
con tutti i sorgenti di esempo in normale formato testuale
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.20. C, C++ and ASM developers
                              and beta testers are welcome!

 formato testuale
Il problema è che un copia incolla (di questo genere) da Python perde
informazioni indispensabili, mentre da C/C++ (o altri linguaggi con
delimitatori) perde informazioni superflue o ridondanti (l'indentazione).
Kiuhnm

 problema del PDF non del Python
MA VA????????????????????
Il problema è che il sorgente pyton è corrotto, quello java no.
-- 
Luc.

 delimitatori) perde informazioni superflue o ridondanti (l'indentazione).
E ricostruibili, tra l'altro.
*** Azimuth ***

 approvi.
Io non sminuisco proprio niente, non e' necessario, gli "altri" ci riescono
bene da soli.


Il problema č che il sorgente pyton č corrotto, quello java no.
questo lo dici tu. Nel sorgente java mancavano pezzi ai margini per
colpa delle istruzioni Java troppo lunghe
tipo buffer con nomi chilometrici :)


 colpa delle istruzioni Java troppo lunghe
Quello è un altro problema...
-- 
Luc.

Maurus,
io ho capito benissimo qual e' il tuo problema, altrimenti non ne staremmo
qui a parlare,
sembra che sia tu che non abbia preso coscienza di qual e' il succo del
discorso.
Il problema di cui tu ti lamenti e' strettamente legato alla tua pratica di
copiare del codice da una fonte che NON E' studiata perche' il codice sia
direttamente trasportabile da un'altra parte, verso un ambiente che richiede
*rigorosita'*. Questo non e' un problema di programmazione in Python. Tu non
mi spieghi nulla di nuovo, e' una questione di principio:
non posso pretendere che del codice esposto in una pubblicazione sia
direttamente trasportabile in un ambiente e utilizzabile. Il fatto che il
PDF ti consenta di fare il copia/incolla non vuol affatto dire che facendo
il copia/incolla tu possa produrre del codice valido (guarda al PDF come se
fosse un libro, un giornale, ha forse senso strappare una pagina di giornale
e cercare di passarla al compilatore ? e' la stessa, identica, cosa).
La perdita della sintassi corretta la *puoi* avere con *qualunque* altro
linguaggio.
Personalmente, non ho mai avuto bisogno di copiare e incollare "centinaia" o
"migliaia" di linee di codice, se tu hai questa necessita', vuol dire che
hai un problema in piu'.
Per concludere: qui dentro si parla di programmazione e il problema che tu
hai non e' un problema di programmazione, ne' e' attribuibile a Python in
alcun modo.
Spero che tu abbia finalmente capito.


Quello č un altro problema...
non tanto differente e non meno importante


 non tanto differente e non meno importante
A me pare che sia totalmente differente.
Perchč fare un thread cosě lungo su un problema tanto evidente?
In Python c'č e in altri linguaggi non c'č.
Non vedo altro da dire.
Kiuhnm


E a proprio piacimento, inoltre :-)
Kiuhnm

In Python c'è e in altri linguaggi non c'è.
Il problema è il PDF non Python, basta usare altri formati meno
"image-related"


 "image-related"
NON HAI CAPITO NIENTE!
Kiuhnm

 E a proprio piacimento, inoltre :-)
Che te ne pare dei test che sto mettendo su? :)
Ciao!
*** Azimuth ***

 NON HAI CAPITO NIENTE!
Non è l'unico purtroppo... ;(
Il livello del NG è proprio basso da quando ho chiesto se veramente 
Python necessitava di forced-indent... Quando mai l'ho fatto!!!
-- 
Luc.

 Che te ne pare dei test che sto mettendo su? :)
Adesso ti risponderò, anche se non mi piacciono le guerre Python VS C, però
è bene dire le cose come stanno.
Python è più facile e appena più lento del C? E no! Troppo comodo!
Perchè invece non diciamo Python è molto più facile, ma anche molto più
lento del C?
Questo è più corretto.
Kiuhnm

 lento del C?
Perche' e' falso, ovviamente. Scommettiamo che domattina ti scrivo un
compilatore Python che traduce in codice superottimizzato per Pentium IV e
ti brucia il codice C ?


 brucia il codice C ?
L'idea non è male, poi si potrebbe anche sviluppare un bel kernel ad
oggetti ;-)
--
ale
www.sen.it

 oggetti ;-)
:,,-D
*** Azimuth ***

 oggetti ;-)
Infatti.


 perde informazioni indispensabili,
prova a rileggere il mio messaggio. Non è difficile


 prova a rileggere il mio messaggio. Non è difficile
Posso rileggerlo finchè vuoi, ma hai spostato il problema dal Python al PDF.
Qui il *clima* è di Python VS C/C++ e si stava dicendo che in C/C++ tale
problema non c'è, nè con i PDF, nè con qualsiasi altro formato/programma.
Questo è difficile da capire, ma forse ce la puoi fare...
Kiuhnm

Posso rileggerlo finchè vuoi, ma hai spostato il problema dal Python al PDF.
il problema è stato spostato al PDF perchè è il PDF il problema


 il problema è stato spostato al PDF perchè è il PDF il problema
Diciamo che il Python mette in risalto il problema, al contrario di altri
linguaggi.
In questo senso il Python è meno robusto :-) ....sto scherzando, ma mi hai
capito...
Kiuhnm

capito...
si ti ho capito, ma direi di dare un taglio alla questione :)


 codice originale.
pdftotext ;-)
-- 
 Ciao, Bianco.                         Reply to luca.bianco (at) 
tiscali.it
|---------[Powered by Debian GNU/Linux 3.0 - 2.2.20 - AMD K6-200]---------|
|------------[Linux Registered User #287769 - Machine #169192]------------|