On Sunday 07 June 2009 10:20:59 Noah Slater wrote: > On Sun, Jun 07, 2009 at 11:07:15PM +0900, Charles Plessy wrote: > > I think that how to specifiy a list of files is in the end in the hands > > of the people writing parsers. > > I think that this optimises for the wrong thing. The parsing code will be > wrote once, or only a few times at most. The file format will be authored > hundreds, if not thousands of time. All other things being equal, it makes > more sense for us to make it easy for packagers. > > > So, from a parser point of view, what would be preferable > > If I was implementing this in Python, it would be easier for me to parse > comma separated values because the "csv" module already handles this. > Unfortunately, if I specified " " as the separator, I would have to quote > filenames instead of escaping any spaces with a reverse solidus.
Some other things to consider. There is Policy 7.1 that defines how to write proper relationship fields. We know that relationship fields are comma-separated, so there are parsers already in programs such as sbuild that read these comma-separated values, and it shouldn't be too hard to modify these parsers to read a 'Files' field (if it were comma-separated). Also, the copyright file should be something that is as simple as possible to read, by a machine but most importantly, by any person. That includes people that are not familiar with shell escaping. I am more inclined to use a comma-separated list as spaces in files and directories are frequently used, as opposed to commas in files and directories, which are quite rare. Consider two examples of a Files field, one space-separated, and one comma-separated. space-separated Files: a\ b c d\ e\ f g.* comma-separated Files: a b, c, d e f, g.* Which implementation could we reasonably expect most people to understand (to include people not knowledgeable with shell escaping)? For example, consider what the two fields may mean to a Windows user. -- Regards, Andres -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
