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
>
>
>  
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.