On Sun, Mar 06, 2011 at 10:34:01AM -0500, Jim Fulton wrote: > An annoyance in buildout configurations, resulting from it's use of > ConfigParser, is that configuration data lines are stripped of leading > spaces. ... > I propose to give buildout it's own parser that begaves like > ConfigParser, with the exeption that leading whitespace won't be > stripped, but will be dedented with textwrap.dedent. > > There is some potential for breakage as some option values without > leading whitespace before would get it now, but my sense is that this > would be unlikely. > > Thoughts? If I did that (and I really want to do this) I'd release a > beta to help people assess the impact.
Woot!
+2
I've had to do contortions like this
initialization =
# haaaaack because zc.recipe.testrunner 1.4.0 produces an _insane_
# bin/test that cannot be run with bin/coverage run bin/test, or even
# bin/python bin/test
import coverage, atexit
c = coverage.coverage(data_file='../../../.coverage')
def _when_done(c=c): c.stop(), c.save()
atexit.register(_when_done)
c.start()
because of that, and because the ${:s} trick never occurred to me.
There's also another -- perhaps minor -- reason to use a custom parser.
That way you could use += more than once in a section, i.e.
develop = foo
develop += bar
develop += baz
as an alternative to
develop = foo
bar
baz
(I've wanted to do that so that I could comment out each develop line
individually, to disable it)
Marius Gedminas
--
#define QUESTION ((bb) || !(bb)) /* Shakespeare */
signature.asc
Description: Digital signature
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
