[FE-discuss] Last patch breaks Py 2.3 compatibility

[Christoph Zwerschke]

Pull request #2 has been accepted and fulfilled by Ian Bicking.
Changes in cbenz/formencode-cbenz have been pulled into
ianb/formencode.

https://bitbucket.org/ianb/formencode/pull-request/2/use-rsplit-x-1-in-variable_decode

Note that formencode so far was meant to work with Py 2.3 (see setup.py)
but rsplit() requires Py 2.4.

Shall we fix this or finally drop Py 2.3 support?

-- Christoph

[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 ;)

Pull request #2 has been accepted and fulfilled by Ian Bicking.
Changes in cbenz/formencode-cbenz have been pulled into
ianb/formencode.
https://bitbucket.org/ianb/**formencode/pull-request/2/use-**

rsplit-x-1-in-variable_decode<https://bitbucket.org/ianb/formencode/pull-request/2/use-rsplit-x-1-in-variable_decode>
Note that formencode so far was meant to work with Py 2.3 (see setup.py)
but rsplit() requires Py 2.4.
Shall we fix this or finally drop Py 2.3 support?
-- Christoph

[Christoph Zwerschke]

Post by 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

[Graham Higgins]

Hi,

Sorry for slight hiatus in responding, email client problems here (sigh)

Post by Christoph Zwerschke

Post by 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.

Post by Christoph Zwerschke
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.

Post by Christoph Zwerschke
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

[Ian Bicking]

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.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Sorry for slight hiatus in responding, email client problems here (sigh)

Post by Christoph Zwerschke

Post by 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

Post by Christoph Zwerschke
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

Post by Christoph Zwerschke
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-----

[Graham Higgins]

Post by Ian Bicking
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
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.

[Chris Lambacher]

Post by Christoph Zwerschke

Post by 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.

Post by Christoph Zwerschke
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?

Post by Christoph Zwerschke
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

[Christoph Zwerschke]

Post by Chris Lambacher

Post by Christoph Zwerschke
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