This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lukasz.langa
Recipients aioryi, brett.cannon, lukasz.langa
Date 2010-07-23.23:46:05
SpamBayes Score 2.1505844e-07
Marked as misclassified No
Message-id <1279928769.44.0.976466347906.issue7113@psf.upfronthosting.co.za>
In-reply-to
Content
Won't happen for Python 2.x but the idea is good. The original patch won't apply for Py3k so I implemented this approach from scratch for Python 3.2. Patch included.

Some microbenchmarks of mine show:
- a 3-5% slowdown for very small files (we can ignore this since it's still a blink of an eye)
- a 10% speedup in usual cases (files the size of a typical Pylons app configuration or a typical buildout)
- more so in unrealistic ones (many values with > 100 lines each)

Brett, a quick summary of changes:
- the idea to introduce a list of lines instead of gluing '%s\n%s' during file reading was introduced
- this approach needs an additional phase of joining the lists to strings after reading is done.
- I used itertools.chain to add the default section for iteration purposes without having to create a separate list. I hope the additional dependency on itertools is no problem.
- I reformatted a bit the changes by fred.drake in r78233 (he added support for valueless keys)
- some other slight formatting changes apply as well
- in the tests I've added a testcase for a file that uses multi-line values heavily. The file is generated temporarily since it's 127kB in size. Creation takes a fraction of a second so shouldn't be noticeable.
History
Date User Action Args
2010-07-23 23:46:09lukasz.langasetrecipients: + lukasz.langa, brett.cannon, aioryi
2010-07-23 23:46:09lukasz.langasetmessageid: <1279928769.44.0.976466347906.issue7113@psf.upfronthosting.co.za>
2010-07-23 23:46:07lukasz.langalinkissue7113 messages
2010-07-23 23:46:06lukasz.langacreate