[Commits] python.it commit r195 -
python/python/Doc/branches/2.4.3/lib
commit a svn.python.it
commit a svn.python.it
Dom 16 Lug 2006 18:16:50 CEST
Author: manlio
Date: Sun Jul 16 18:16:49 2006
New Revision: 195
Modified:
python/python/Doc/branches/2.4.3/lib/emailmimebase.tex
python/python/Doc/branches/2.4.3/lib/emailparser.tex
Log:
aggiornamenti - Antonio Vitale
Modified: python/python/Doc/branches/2.4.3/lib/emailmimebase.tex
==============================================================================
--- python/python/Doc/branches/2.4.3/lib/emailmimebase.tex (original)
+++ python/python/Doc/branches/2.4.3/lib/emailmimebase.tex Sun Jul 16 18:16:49 2006
@@ -183,9 +183,7 @@
%[- MARK -] END DIFF
\end{classdesc}
-\begin{classdesc}{MIMEText}{_text\optional{, _subtype\optional{,
- _charset\optional{, _encoder}}}}
-
+\begin{classdesc}{MIMEText}{_text\optional{, _subtype\optional{, _charset}}}
Una sotto classe di \class{MIMENonMultipart}, la classe
\class{MIMEText} viene utilizzata per creare oggetti MIME,
principalmente di tipo \mimetype{text}. \var{_text} è la stringa per
@@ -196,7 +194,7 @@
Non viene effettuata alcuna analisi per determinare la codifica del
testo.
-\deprecated{2.2.2}{L'argomento \var{_encoding} è considerato
-deprecato. La codifica adesso viene implicitamente basata
-sull'argomento \var{_charset}.}
+\versionchanged[L'argomento deprecato precedente \var{_encoding} è
+stato eliminato. La codifica adesso viene implicitamente basata
+sull'argomento \var{_charset}.}
\end{classdesc}
Modified: python/python/Doc/branches/2.4.3/lib/emailparser.tex
==============================================================================
--- python/python/Doc/branches/2.4.3/lib/emailparser.tex (original)
+++ python/python/Doc/branches/2.4.3/lib/emailparser.tex Sun Jul 16 18:16:49 2006
@@ -143,30 +143,79 @@
%[- MARK -] END DIFF
e \method{walk()}.
-Notare che il parser può essere esteso in modo illimitato ed ovviamente
+Attualmente sono pronte all'uso due differenti interfacce per il parser:
+la classica API \class{Parser} e l'API incrementale \class{FeedParser}.
+La classica API \class{Parser} è perfetta nel caso l'intero testo del
+messaggio sia memorizzato in una stringa, oppure risieda per intero in un
+file del file system. \class{FeedParser} è più adatta durante la lettura del
+messaggio a partire da un flusso che potrebbe interrompersi nell'attesa di altri
+input (ad es. la lettura da un socket di un messaggio email). \class{FeedParser} può
+effettuare l'analisi del messaggio in modo incrementale, restituendo l'oggetto
+principale solamente al momento della chiusura del parser\footnote{come nel package
+email versione 3.0, introdotto in Python 2.4, il classico \class{Parser} è stato
+implementato di nuovo secondo la classe \class{FeedParser}, così sia la semantica
+adottata che i risultati dei due parser sono diventati identici.}.
+
+Notare che il parser può essere esteso in modo limitato ed ovviamente
è possibile implementare un parser partendo da zero. Non ci sono
connessioni magiche tra il parser allegato al package \module{email} e
la classe \class{Message}, quindi un parser personalizzato può
-creare alberi di oggetti messaggio in ogni modo si ritenga necessario.
+creare alberi di oggetti messaggio in ogni modo si ritenga necessario.
+
+\subsubsection{FeedParser API}
+
+\versionadded{2.4}
+
+La \class{FeedParser} fornisce un'API che contribuisce all'analisi incrementale
+dei messaggi email che potrebbe rendersi necessaria durante la lettura del testo
+di un messaggio email da una sorgente che può interrompersi (ad.es. un socket).
+Naturalmente \class{FeedParser} può venire usata per analizzare un messaggio
+email contenuto interamente in una stringa oppure in un file. La semantica ed i
+risultati dei due parser sono gli stessi.
+
+l'API di \class{FeedParser} è semplice; si crea un'istanza, la si alimenta con
+un pacchetto di testo finché non c'è altro da fornirgli, quindi si chiude il
+parser per richiamare l'oggetto originale message. \class{FeedParser} è
+estremamente accurata quando analizza messaggi standardizzati e svolge un ottimo
+lavoro nell'analizzare quelli non standard, fornendo informazioni su come un
+messaggio non sia stato ritenuto decifrabile. Riempirà gli attributi \var{defects}
+di un oggetto message con una lista dei problemi che vi sono stati riscontrati.
+Si veda il modulo \refmodule{email.Errors} per una elenco dei difetti che può trovare.
+
+Ecco l'API per la classe \class{FeedParser}:
+
+\begin{classdesc}{FeedParser}{\optional{_factory}}
+Crea un'istanza della classe \class{FeedParser}. \var{_factory} è un no-argument
+richiamabile che può essere chiamato ogni qqual volta un nuovo oggetto messagge
+sia necessario. E' predefinito alla classe \class{email.Message.Message}.
+\end{classdesc}
+
+\begin{methoddesc}[FeedParser]{feed}{data}
+Fornisce altri dati a \class{FeedParser}. \var{data} deve essere una stringa
+costituita da una o più linee. Tali linee possono essere anche parziali ed in
+tal caso \class{FeedParser} le unirà nel modo corretto. Le linee presenti nella
+stringa possono contenere qualunque dei tre caratteri di fine riga: ritorno a capo,
+nuova linea oppure ritorno a capo e nuova linea (possono anche essere mischiati).
+\end{methoddesc}
-Il parser primario è \class{Parser}, che analizza sia l'intestazione
-che il carico utile del messaggio. Nel caso di messaggi
-\mimetype{multipart}, analizzerà ricorsivamente il corpo del messaggio
-contenitore. Sono supportate due modalità di analisi, quella
-\emph{rigorosa}, che generalmente rigetterà ogni messaggio non
-compatibile con l'RFC, e quella \emph{lasca}, che proverà a
-sistemare i problemi di formattazione di MIME più comuni.
-
-Il modulo \module{email.Parser} fornisce anche una seconda classe,
-chiamata \class{HeaderParser} che può essere utilizzata se si è solo
-interessati nelle intestazioni del messaggio. \class{HeaderParser}
+\begin{methoddesc}[FeedParser]{close}{}
+Chiude una classe \class{FeedParser} completando l'analisi di tutti i dati alimentati
+precedentemente e ritorna l'oggetto originale message. E' del tutto sconosciuto
+cosa avviene alimentando altri dati ad una classe \class{FeedParser} già chiusa.
+\end{methoddesc}
+
+\subsubsection{Parser class API}
+
+La \class{Parser} fornisce un'API che può essere impiegata per l'analisi di un
+messaggio quando l'intero contenuto di esso è disponibile in una stringa oppure
+un file. Il modulo \module{email.Parser} fornisce una seconda classe, chiamata
+\class{HeaderParser} che può essere utilizzata se si è solo
+interessati alle intestazioni del messaggio. \class{HeaderParser}
può essere molto più veloce in queste situazioni, poiché non prova ad
analizzare il corpo del messaggio, in sostituzione imposta il carico
utile al corpo del messaggio grezzo, come una stringa.
\class{HeaderParser} ha la stessa API della classe class{Parser}.
-\subsubsection{API per la classe Parser}
-
\begin{classdesc}{Parser}{\optional{_class\optional{, strict}}}
Il costruttore per la classe \class{Parser} riceve un argomento
facoltativo \var{_class}. Questo deve essere interno al costruttore e
@@ -175,20 +224,14 @@
\class{Message} (vedere \refmodule{email.Message}). La funzionalità
interna verrà chiamata senza argomenti.
-L'opzione facoltativa \var{strict} specifica se dovrà essere
-effettuata un'analisi rigorosa o lasca. Normalmente, quando cose come
-i limiti di MIME mancano o quando i messaggi hanno problemi di
-formattazione, \class{Parser} solleva un'eccezione
-\exception{MessageParseError}. Comunque, quando viene abilitata
-l'analisi lasca, \class{Parser} prova a lavorare su questi errori di
-formattazione per generare una struttura del messaggio utilizzabile
-(questo non significa che \exception{MessageParseError} non verrà mai
-sollevata; alcuni messaggi formattati male non possono semplicemente
-essere analizzati). Il valore predefinito dell'opzione \var{strict} è
-\code{False}, poichè l'analisi lasca fornisce generalmente un
-comportamento più conveniente.
-\versionchanged[\`E stata aggiunta l'opzione \var{strict}]{2.2.2}
+L'opzione facoltativa \var{strict} è ignorato. \deprecated{2.4}{Perchè la
+classe \class{Parser} è retro-compatibile con il nuovo wrapper API \class{FeedParser}
+presente in Python 2.4, il parsing di \emph{all} è effettivamente non-strict.
+Si deve semplicemente non passare più l'opzione facoltativa \var{strict} al
+costruttore \class{Parser}}.
+
+\versionchanged[\E' stata deprecata l'opzione \var{strict}]{2.4}
\end{classdesc}
Gli altri metodi pubblici di \class{Parser} sono:
@@ -302,5 +345,14 @@
una lista di carico utile di lunghezza 1. Il metodo
\method{is_multipart()} restituirà \code{True}. Il singolo
elemento nella lista di carico utile sarà un oggetto di tipo
- sub-message.
+ sub-message.
+
+\item Alcuni del messaggi che non rispettano uno standard potrebbero essere
+ incosistenti al loro interno a causa della loro \mimetype{multipart}
+ tipologia. Questi messaggi potrebbero avere un'intestazione
+ \mailheader{Content-Type} del tipo \mimetype{multipart}, ma il loro
+ metodo \method{is_multipart()} potrebbe restituire \code{False}. Se tali
+ messaggi vengono analizzati con \class{FeedParser}, avranno un'istanza
+ della classe \class{MultipartInvariantViolationDefect} nel loro elenco di
+ attributi \var{defects}. Per più dettagli si veda \refmodule{email.Errors}.
\end{itemize}
Maggiori informazioni sulla lista
Commits