On Mon, Mar 4, 2013 at 9:33 AM, pombredanne <notifications@github.com>wrote:

> In src/zc/buildout/configparser.py:
>
> > +section_header  = re.compile(
> > +    r'(?P<head>\[)'            # opening bracket [ starts a section title line
> > +    r'\s*'
> > +    r'(?P<name>[^\s[\]:{}]+)'  # section name
> > +    r'\s*'
> > +    r'('
> > +     r']'                      # closing bracket ]
> > +     r'\s*'
> > +     r'([#;].*)?$'             # optional trailing comment marked by '#' or ';'
> > +    r'|'                       # OR
> > +     r':'                      # optional ':' separator for expression
> > +     r'\s*'
> > +     r'(?P<tail>.*'            # optional arbitrary Python expression
> > +     r']'                      # closing bracket ]
> > +     r'\s*'
> > +     r'\#?.*)$'                # optional trailing comment marked by '#'
>
> @jimfulton <https://github.com/jimfulton> I get your point on the comment
> restriction, but frankly I could find neither an example of a buildout
> config file in the wild using a comment after the section name, nor using
> the ";" semicolon as a trailing comment separator for a header line.
> Note that this comment restriction would be only when using a header
> expression and does not apply otherwise, and that there are no other
> restrictions imposed on the Python expression beyond it being a valid
> expression
>
The problem is having a comment syntax work sometimes and not others.
If we were going restrict comments to #s sometimes, then I'd want to always
restrict it, which would be a backward-incompatible change.

On the other hand adding a restriction that the expression cannot contain #
> or ; means that expression literals would not be able to contain this
> characters (and not only the variable names, which is already impossible as
> this would not parse to a valid expression during evaluation
>

Right, but why would you want to include these characters?  The only ways
that make sense are:

1) as Python comments.

    This would break your parsing approach, as it would hide the closing ].

    This breakage is possible in the current implementation:

         [foo: 2 # ha]

2) In string literals.

    I think the likelihood.  In the wildly unlikely case that this is
needed,
    someone could express these characters using escapes. (\x3b).