[Python-checkins] python/nondist/peps pep-0305.txt,1.15,1.16
goodger@users.sourceforge.net
goodger@users.sourceforge.net
Fri, 21 Mar 2003 22:38:54 -0800
Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1:/tmp/cvs-serv31939
Modified Files:
pep-0305.txt
Log Message:
fixed lists
Index: pep-0305.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0305.txt,v
retrieving revision 1.15
retrieving revision 1.16
diff -C2 -d -r1.15 -r1.16
*** pep-0305.txt 13 Feb 2003 19:01:17 -0000 1.15
--- pep-0305.txt 22 Mar 2003 06:38:51 -0000 1.16
***************
*** 28,32 ****
- Better motivation for the choice of passing a file object to the
! constructors. See http://manatee.mojam.com/pipermail/csv/2003-January/000179.html
- Unicode. ugh.
--- 28,33 ----
- Better motivation for the choice of passing a file object to the
! constructors. See
! http://manatee.mojam.com/pipermail/csv/2003-January/000179.html
- Unicode. ugh.
***************
*** 40,55 ****
mechanisms and line endings. The authors intend the proposed module
to solve this one parsing problem efficiently. The authors do not
! intend to address any of these related topics::
! - data interpretation (is a field containing the string "10"
! supposed to be a string, a float or an int? is it a number in
! base 10, base 16 or base 2? is a number in quotes a number or a
! string?)
! - locale-specific data representation (should the number 1.23 be
! written as "1.23" or "1,23" or "1 23"?) -- this may eventually
! be addressed.
! - fixed width tabular data - can already be parsed reliably.
--- 41,55 ----
mechanisms and line endings. The authors intend the proposed module
to solve this one parsing problem efficiently. The authors do not
! intend to address any of these related topics:
! - data interpretation (is a field containing the string "10" supposed
! to be a string, a float or an int? is it a number in base 10, base
! 16 or base 2? is a number in quotes a number or a string?)
! - locale-specific data representation (should the number 1.23 be
! written as "1.23" or "1,23" or "1 23"?) -- this may eventually be
! addressed.
! - fixed width tabular data - can already be parsed reliably.
***************
*** 247,288 ****
In addition to the dialect argument, both the reader and writer
constructors take several specific formatting parameters, specified as
! keyword parameters. The formatting parameters understood are::
! - ``quotechar`` specifies a one-character string to use as the
! quoting character. It defaults to '"'. Setting this to None
! has the same effect as setting quoting to csv.QUOTE_NONE.
! - ``delimiter`` specifies a one-character string to use as the
! field separator. It defaults to ','.
! - ``escapechar`` specifies a one-character string used to escape
! the delimiter when quotechar is set to None.
! - ``skipinitialspace`` specifies how to interpret whitespace which
! immediately follows a delimiter. It defaults to False, which
! means that whitespace immediately following a delimiter is part
! of the following field.
! - ``lineterminator`` specifies the character sequence which should
! terminate rows.
! - ``quoting`` controls when quotes should be generated by the
! writer. It can take on any of the following module constants::
! * csv.QUOTE_MINIMAL means only when required, for example,
! when a field contains either the quotechar or the delimiter
! * csv.QUOTE_ALL means that quotes are always placed around
! fields.
! * csv.QUOTE_NONNUMERIC means that quotes are always placed
! around nonnumeric fields.
! * csv.QUOTE_NONE means that quotes are never placed around
! fields.
! - ``doublequote`` controls the handling of quotes inside fields.
! When True two consecutive quotes are interpreted as one during
! read, and when writing, each quote is written as two quotes.
When processing a dialect setting and one or more of the other
--- 247,286 ----
In addition to the dialect argument, both the reader and writer
constructors take several specific formatting parameters, specified as
! keyword parameters. The formatting parameters understood are:
! - ``quotechar`` specifies a one-character string to use as the quoting
! character. It defaults to '"'. Setting this to None has the same
! effect as setting quoting to csv.QUOTE_NONE.
! - ``delimiter`` specifies a one-character string to use as the field
! separator. It defaults to ','.
! - ``escapechar`` specifies a one-character string used to escape the
! delimiter when quotechar is set to None.
! - ``skipinitialspace`` specifies how to interpret whitespace which
! immediately follows a delimiter. It defaults to False, which means
! that whitespace immediately following a delimiter is part of the
! following field.
! - ``lineterminator`` specifies the character sequence which should
! terminate rows.
! - ``quoting`` controls when quotes should be generated by the writer.
! It can take on any of the following module constants::
! * csv.QUOTE_MINIMAL means only when required, for example, when a
! field contains either the quotechar or the delimiter
! * csv.QUOTE_ALL means that quotes are always placed around fields.
! * csv.QUOTE_NONNUMERIC means that quotes are always placed around
! nonnumeric fields.
! * csv.QUOTE_NONE means that quotes are never placed around fields.
! - ``doublequote`` controls the handling of quotes inside fields. When
! True two consecutive quotes are interpreted as one during read, and
! when writing, each quote is written as two quotes.
When processing a dialect setting and one or more of the other
***************
*** 331,335 ****
-
Issues
======
--- 329,332 ----
***************
*** 377,384 ****
csv.py.
! 8. Are quote character and delimiters limited to single characters?
For the time being, yes.
! 9. How should rows of different lengths be handled? Interpretation of
the data is the application's job. There is no such thing as a
"short row" or a "long row" at this level.
--- 374,381 ----
csv.py.
! 7. Are quote character and delimiters limited to single characters?
For the time being, yes.
! 8. How should rows of different lengths be handled? Interpretation of
the data is the application's job. There is no such thing as a
"short row" or a "long row" at this level.