Re: pyblosxom future (1.3/2.0)
Doug Ransom <doug.ransom-cmaem7PIVQRoiclzN/[email protected]>
| Newsgroups | gmane.comp.web.pyblosxom.devel |
|---|---|
| Message-ID | <[email protected]> |
Bill Mill wrote: >On Mon, 28 Mar 2005 07:46:58 -0800, Doug Ransom <idlsfy-UJU/[email protected]> wrote: > > >>I just joined after the * pyblosxom future (1.3/2.0)* announcement by >>Will. >> >>I propose for 1.3, the entire pyblosxom code base and a good chunk of >>the contrib package be provided with unit tests, so they can be >>refactored. This would make it way easier for people to add or refactor >>code. >> >> >> > >agreed - I don't think anybody's opposed to this. Problem is, no one >wants to write them. > > Hm. The benefits are huge (coding should be faster, debugging easier), Test Driven Development looks good on resumes too. What can we do to help people want to write test suites? Do they really not want to write them, or do they not want to write one or two when nobody else is doing it? It might be interesting to have a 1.25 release, which is 1.2 with a suite of tests for a tested/testable pyblosxom (i.e. no new features) and 2 or three plug ins. > > >>For example, I am struggling with the pycategories code. I would like >>different html output, and I cannot figure out how to run/debug the code >>without hitting a webserver (I could probably fake a cgi call with >>komodo, but thats not much better). >> >> >> > >we'll have to figure something out. Maybe a way to start would be to >write a function which generates Request objects without an actual >request, since almost all functions in pyblosxom act on the request >object. > > > >>It would be cool to have a shipping blog with predefined entries, >>directories, etc., and a way to test/debug any of the plugins. >> >> >> > >what do you mean by predefined entries, directories, etc? I agree that >unit tests would be good, but I'm not sure what you mean here. > > Basically, a predefied environment on which tests can run, installed with pyblosxom. > > >>I think this would also be a good time to switch to python 2.4 and allow >>the code to use any newer features. >> >> > >We've talked about moving to python 2.3, but I think we agreed that we >don't want to get 2.4-specific. I don't see any reason to prefer 2.4 >over 2.3 that overrides backwards compatibility. > > Well, the main reason in my opinion to move to 2.4 is so that the code evolves in the best way possible, rather than being second-grade to support legacy versions of python. I don't think many people running pyblosxom are going to grumbly about upgrading to python 2.4. >Peace >Bill Mill >bill.mill at gmail.com > > > >