Menu
▾
▴
formencode-discuss
|
From: Christoph Z. <ci...@on...> - 2011-07-06 21:54:50
|
Am 05.07.2011 18:36 schrieb Bitbucket: > 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 |
|
From: Ian B. <ia...@co...> - 2011-07-06 22:04:51
|
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 ;) On Wed, Jul 6, 2011 at 4:54 PM, Christoph Zwerschke <ci...@on...> wrote: > Am 05.07.2011 18:36 schrieb Bitbucket: > > 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 > |
|
From: Christoph Z. <ci...@on...> - 2011-07-07 10:05:26
|
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 |
|
From: Graham H. <gjh...@be...> - 2011-07-07 13:06:05
|
-----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----- |
|
From: Ian B. <ia...@co...> - 2011-07-07 17:02:15
|
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 <gj...@be...> 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----- > |
|
From: Graham H. <gjh...@be...> - 2011-07-08 02:43:00
|
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/ |
|
From: Chris L. <ch...@ka...> - 2011-07-08 15:00:56
|
On Thu, Jul 7, 2011 at 6:05 AM, Christoph Zwerschke <ci...@on...> 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 |
|
From: Christoph Z. <ci...@on...> - 2011-07-08 15:45:47
|
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
|
Thanks for helping keep SourceForge clean.
X