Hi everyone!
As you might know, I've been trying to look for new maintainers for a lot of
my projects (Paste or PasteScript anyone?). I found some new maintainers a
while ago for FormEncode, but we've been a bit pokey formalizing it. But:
let it be formalized! Especially since there's some more activity around
the project lately.
Daniel Stanek is taking up primarily maintainership, and Chris Lambacher has
also offered to comaintain. Thanks guys!
There's a new group repository,
https://bitbucket.org/formencode/official-formencode -- though it looks like
it needs to pick up some stuff still. I'm not exactly sure how to manage
that change on BitBucket (i.e., how to get pulls and whatnot directed at
this new repo).
Cheers,
Ian

Am 08.07.2011 17:00 schrieb Chris Lambacher:
>> If we drop it, I am willing to go through the code and simplify it
>> based on Py 2.4 (use decorators etc.)
>
> You have something specific in mind here?
For example, the following code:
def _repr_vars(dictNames):
names = [n for n in dictNames
if not n.startswith('_') and n != 'declarative_count']
names.sort()
return names
_repr_vars = staticmethod(_repr_vars)
could be written in Py 2.4 as:
@staticmethod
def _repr_vars(dictNames):
return sorted(n for n in dictNames
if not n.startswith('_') and n != 'declarative_count')
Things like that.
-- Christoph

On Thu, Jul 7, 2011 at 6:05 AM, Christoph Zwerschke <cito@...> wrote:
> Am 07.07.2011 00:04 schrieb Ian Bicking:
>> I ended up reverting that change because it also broke tests, and once I
>> looked at it I didn't understand the purpose anyway. Not that I mind
>> dropping 2.3 support ;)
>
> Since the 2to3 patch by Graham Higgins also requires Py 2.4, dropping
> 2.3 support would be a step forward I think.
+1
2.3 is getting pretty long in the tooth and 2.4 is a fairly large
milestone release.
>
> If we drop it, I am willing to go through the code and simplify it based
> on Py 2.4 (use decorators etc.)
You have something specific in mind here?
> But I suggest creating a final 1.2.5 release with Py 2.3 support before
> doing this and then having a 1.3 which requires Py 2.4 after the
> overhaul, maybe already with Graham's patch.
+1
We should also triage any critical bugs before a 1.2.5 release and
make sure that we don't have to maintain 1.2.x for a long time. Any
idea about the user base still on 2.3?
-Chris Lambacher

On Thu, 2011-07-07 at 12:01 -0500, Ian Bicking wrote:
> Oh, are we talking about Python 3 porting too? Huh, I haven't been
> keeping track. Another guy also worked on Python 3 porting, as a
> prerequisite for porting SQLObject. His work is here:
> https://bitbucket.org/fetchinson/formencode-py3k/overview -- I just
> read the changes, but it looked fairly complete to me.
My effort was a sort of a semi-accidental port to Python 3, driven
mainly by curiosity and self-interest. A casual application of 2to3
showed a lot of promise, suggesting that just a few hard-coded
sys.version switches were required to cover the gaps. formencode has the
advantage that it's pretty much self-contained.
I was aware of Daniel Fetchinson's work on a port but, as I didn't/don't
have much familiarity with the codebase, I wasn't really able to assess
how much of the task remained to be done. I couldn't quite make out
Daniel's intentions for the port because his choosing to use the 2.4
collections module would definitely rule out support for 2.3 and yet the
mainstream commit comments indicated that support for 2.3 was still an
existing requirement. AFAIK, there's no a priori reason why a
2to3-driven port would rule out support for Python 2.3, so I ploughed my
own furrow.
As it transpired, I managed to solve the compilation issue and I can
confirm that all the tests pass with Python 2.3.
I've inserted a separate Python2.3 nosetests run into the hudson build
script. It won't run under tox because that, via virtualenv, requires
2.4's subprocess module
Supporting 2.3 does carry some disproportionate effort but it would seem
that a 2to3 solution doesn't necessarily have to have any impact on that
issue either way - but more extensive test coverage would help clarify
that, I s'pose.
--
Graham Higgins
http://bel-epa.com/gjh/

Oh, are we talking about Python 3 porting too? Huh, I haven't been keeping
track. Another guy also worked on Python 3 porting, as a prerequisite for
porting SQLObject. His work is here:
https://bitbucket.org/fetchinson/formencode-py3k/overview -- I just read the
changes, but it looked fairly complete to me.
On Thu, Jul 7, 2011 at 7:45 AM, Graham Higgins <gjh@...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> Sorry for slight hiatus in responding, email client problems here (sigh)
>
>
> On 7 Jul 2011, at 11:05, Christoph Zwerschke wrote:
>
> Am 07.07.2011 00:04 schrieb Ian Bicking:
>>
>>> I ended up reverting that change because it also broke tests, and once I
>>> looked at it I didn't understand the purpose anyway. Not that I mind
>>> dropping 2.3 support ;)
>>>
>>
>> Since the 2to3 patch by Graham Higgins also requires Py 2.4, dropping
>> 2.3 support would be a step forward I think.
>>
>
> For completeness, I'd have preferred to have 2.3 coverage but ...
>
> The omission of 2.3 was simply (but significantly) because I couldn't get
> the official tarball to compile on ubuntu natty - which otherwise provides
> distro package support for 2.5, 2.6, 2.7, 3.1 and 3.2. There's a separate,
> individually-maintained "deadsnakes" ppa which provides a suitable 2.4
> package (bless their little cotton socks) but for 2.3 one is left with the
> "./configure && make" option - which blows out on both my laptop and the
> server. Obviously, a CentOS 4 VM would likely do the trick but even at that
> the relentless march of time means that supporting 2.3 is edging towards
> becoming disproportionately expensive in maintenance terms.
>
>
> If we drop it, I am willing to go through the code and simplify it based
>> on Py 2.4 (use decorators etc.)
>>
>
> There's a current GSOC project aimed at porting webob to Python 3. The
> project kicked off with a test sprint aimed at achieving 100% test coverage,
> considered to be a highly desirable precondition for a robust port and also
> no bad thing in itself. I suspect formencode would similarly benefit from
> extended test coverage. It took 'em three days, mind.
>
>
> But I suggest creating a final 1.2.5 release with Py 2.3 support before
>> doing this and then having a 1.3 which requires Py 2.4 after the
>> overhaul, maybe already with Graham's patch.
>>
>
> Makes a lot of sense to me, fwiw. My perspective here is enlightened
> self-interest (as a formencode user) and a respect for formencode's
> extensive existing i18n .po coverage, an aspect whose importance is
> sometimes severely under-appreciated by native English speaking developers
> (though I note this is definitely not true of Ian). And I've seen a few
> "formencode is dead, it isn't being supported" misperceptions being bruited
> about on IRC.
>
> I'd certainly be prepared to set up another CI job to track and support a
> development repository if that's perceived as a useful contribution. I'll
> also pitch in with the coding where I can (I'm a cognitive psychologist by
> trade, not a pro coder).
>
> Cheers,
>
> Graham Higgins
>
> -----BEGIN PGP SIGNATURE-----
>
> iEYEARECAAYFAk4VqmQACgkQOsmLt1**NhivwrJQCgtGdOuHlx/**NjWiTURq1Yf8qZA
> 58AAnj7skEfOrLICnvVc5ZZCr+p/**XTKoiQCVAgUBThWqZFnrWVZ7aXD1AQ**LWlgQA
> yTx+**z1bFpYzfxkMTQwwH5LDhbQr7O7ZSaP**3J4MvDejnNqYQ7VvTKvM/+W9gSGT9G
> EqrF+3vT459Go3blYyI+**Q2QpBQl8CAOsZvVPa3ufuPUpGpwuAt**k8iFTxEYMusqmT
> RHJYxP8wdh8XTEe523L0px0uzOFRhQ**Fc7N8HFTft78Y=
> =i4gu
> -----END PGP SIGNATURE-----
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Sorry for slight hiatus in responding, email client problems here (sigh)
On 7 Jul 2011, at 11:05, Christoph Zwerschke wrote:
> Am 07.07.2011 00:04 schrieb Ian Bicking:
>> I ended up reverting that change because it also broke tests, and
>> once I
>> looked at it I didn't understand the purpose anyway. Not that I mind
>> dropping 2.3 support ;)
>
> Since the 2to3 patch by Graham Higgins also requires Py 2.4, dropping
> 2.3 support would be a step forward I think.
For completeness, I'd have preferred to have 2.3 coverage but ...
The omission of 2.3 was simply (but significantly) because I couldn't
get the official tarball to compile on ubuntu natty - which otherwise
provides distro package support for 2.5, 2.6, 2.7, 3.1 and 3.2.
There's a separate, individually-maintained "deadsnakes" ppa which
provides a suitable 2.4 package (bless their little cotton socks) but
for 2.3 one is left with the "./configure && make" option - which
blows out on both my laptop and the server. Obviously, a CentOS 4 VM
would likely do the trick but even at that the relentless march of
time means that supporting 2.3 is edging towards becoming
disproportionately expensive in maintenance terms.
> If we drop it, I am willing to go through the code and simplify it
> based
> on Py 2.4 (use decorators etc.)
There's a current GSOC project aimed at porting webob to Python 3.
The project kicked off with a test sprint aimed at achieving 100%
test coverage, considered to be a highly desirable precondition for a
robust port and also no bad thing in itself. I suspect formencode
would similarly benefit from extended test coverage. It took 'em
three days, mind.
> But I suggest creating a final 1.2.5 release with Py 2.3 support
> before
> doing this and then having a 1.3 which requires Py 2.4 after the
> overhaul, maybe already with Graham's patch.
Makes a lot of sense to me, fwiw. My perspective here is enlightened
self-interest (as a formencode user) and a respect for formencode's
extensive existing i18n .po coverage, an aspect whose importance is
sometimes severely under-appreciated by native English speaking
developers (though I note this is definitely not true of Ian). And
I've seen a few "formencode is dead, it isn't being supported"
misperceptions being bruited about on IRC.
I'd certainly be prepared to set up another CI job to track and
support a development repository if that's perceived as a useful
contribution. I'll also pitch in with the coding where I can (I'm a
cognitive psychologist by trade, not a pro coder).
Cheers,
Graham Higgins
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAk4VqmQACgkQOsmLt1NhivwrJQCgtGdOuHlx/NjWiTURq1Yf8qZA
58AAnj7skEfOrLICnvVc5ZZCr+p/XTKoiQCVAgUBThWqZFnrWVZ7aXD1AQLWlgQA
yTx+z1bFpYzfxkMTQwwH5LDhbQr7O7ZSaP3J4MvDejnNqYQ7VvTKvM/+W9gSGT9G
EqrF+3vT459Go3blYyI+Q2QpBQl8CAOsZvVPa3ufuPUpGpwuAtk8iFTxEYMusqmT
RHJYxP8wdh8XTEe523L0px0uzOFRhQFc7N8HFTft78Y=
=i4gu
-----END PGP SIGNATURE-----

Am 07.07.2011 00:04 schrieb Ian Bicking:
> I ended up reverting that change because it also broke tests, and once I
> looked at it I didn't understand the purpose anyway. Not that I mind
> dropping 2.3 support ;)
Since the 2to3 patch by Graham Higgins also requires Py 2.4, dropping
2.3 support would be a step forward I think.
If we drop it, I am willing to go through the code and simplify it based
on Py 2.4 (use decorators etc.)
But I suggest creating a final 1.2.5 release with Py 2.3 support before
doing this and then having a 1.3 which requires Py 2.4 after the
overhaul, maybe already with Graham's patch.
-- Christoph