[Csv] Status

[Andrew McNamara]

>In the C code can't you just look up "split", "join", "__add__" and such and
>not care that you are dealing with string or unicode objects?  Even better,
>can't you just make heavy use of the abstract interface which implements
>many of the things that are trivial in Python code?

Currently the C module just deals with raw strings. I suspect there
would be a fair performance cost to using the string object's methods
(I should have a look at how strings and unicode strings are implemented
internally these days).  Suffice to say, it's a reasonable amount of work. 

We probably should be focusing on refining the PEP and writing some tests
at this stage... 8-)

Regarding the PEP -

 - are we going to retain the ability to pass keyword arguments, that
   override the dialect, to the factory functions (the pep doesn't mention
   this)?

 - we could make the dialect parameter accept either a string dialect name
   or a dialect instance - is this a good idea?

 - regarding the dialect list function - this probably should be called
   list_dialects(), yes?

 - should we call the delimiter parameter "field_sep" instead (I
   notice you haven't used underscores in the parameter names - is
   this deliberate)?

Thinking about the tests, I envisage a bunch of tests for the underlying
C module, and tests for each dialect (just the basic dialect with no
additional parameters)?

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/