On 04/19/2010 12:22 PM, Stromberg, Dan wrote:
On 04/19/2010 12:17 PM, Stromberg, Dan wrote:
  
On 04/19/2010 11:44 AM, Trans wrote:
   
    
On Apr 19, 2:16 pm, Dan Stromberg<dan.stromb...@hp.com>   wrote:

     
      
We have a build process that uses YAML - pyyaml specifically, not
pyyaml-legacy.

When our automated processes put things in the YAML files, the YAML
parsing works.  But every once in a while a human adds something to a
YAML file, and sometimes these humans don't add blanks after the colons,
and then the process blows up.

I've been asked to come up with a YAML parser that will be more lenient
about not having a blank after a colon.  EG, right now, this doesn't
work for us:

invoice: 34843
date   : 2001-01-23
bill-to:&id001
       given  :Chris
       family : Dumars

...because "given  :Chris" has no space after the colon.

So I have some questions:
1) Is there already a YAML parser that relaxes this?
2) How can I tell what version of pyyaml we are using?  I see the module
names match those of pyyaml, but when grep'ing those modules for
"version", I don't see anything that looks like a version string
3) I see that pyyaml's trunk has a "tests" directory - how would I
invoke these?  Can anyone comment on how comprehensive these tests are?
4) Does pyyaml currently insist on a blank after a colon for a good
reason?  Would eliminating the requirement introduce an ambiguity?

       
        
Maybe a simple pre-parser suffice?

     
      
I was thinking a sed -i might do it, but then I'm not quite sure where
to insert the sed at this point.  Also, I have a feeling my management
will prefer a change to the parser.

I found that you can run "python setup.py test" for part of my question
#3 above.  It gives a C compile error, and then appears to continue
testing using pure python code.  The final line of output is "TESTS:
1268" - how does one interpret that?

Thanks!
   
    
It just occured to me - we could replace the file open with a 
subprocess.Popen - but I still suspect my management may favor a change 
to the python parser, assuming that won't introduce an ambiguity.
  

About question #3:
I see that the README says the unit tests are comprehensive.

Also, I intentionally introduced an error and then ran the tests, and got:
TESTS: 1268
ERRORS: 986
...which seems pretty self-explanatory now.
I'm still interested in answers to questions 1, 2, and 4 above.  And if someone has something further to add to #3, I certainly wouldn't be displeased ^)^

Thanks!