On 02/02/2006, at 5:54 PM, Nicolas Lehuen wrote:
Having read your work on Vampire (and its
module importing mechanism) I'm pretty sure it won't be long.
The new importer is actually a complete rewrite and some things
are done quite differently to what was done in Vampire. I have in
effect rew
I am hereby happy to tell you that by removing the call to enumerate()
in the publisher code, the whole test suite passes on Python 2.2
without any further patch or hack. I've checked in the modification
which this time should not pose any problem since it's pretty basic
and non intrusive.
Regards
PythonImport that works for any interpreter.
Key: MODPYTHON-117
URL: http://issues.apache.org/jira/browse/MODPYTHON-117
Project: mod_python
Type: Wish
Components: core
Versions: 3.2
Reporter: Graham Dumplet
Nicolas Lehuen wrote:
We should also agree that if we do do a 3.2.7 what will be fixed in it
and this time set a strict time frame on how long we let it be tested.
Do we leave it at stat.ST_MTIME, or also add the connection handler
fix as well if we are happy with that? Is a "b" designation neede
2006/2/2, Jim Gallacher <[EMAIL PROTECTED]>:
> If we are going to do a 3.2.7, let's just do it. Either spend a couple
> of days debating the merits of 3.2.7 or a couple of days *testing* it. :)
>
> My list for 3.2.7
> connection handler fix so it passes the unit tests
I'll let you pros do that :
Jim Gallacher writes:
> Daniel J. Popowich wrote:
> > Regardless, I do not think it is within the scope of mod_python
> > developers to keep users forward-compatible with the underlying python
> > version. Sorry, but IMHO, this is not scalable software engineering.
>
> I'll re-read this paragrap
My official vote is eventually -1 for 3.2.6, see the previous
discussion for why I've changed my mind.
However I'm +1 on releasing 3.2.7 without a restrained testing period,
not a long one like for 3.2.6.
Regards,
Nicolas
2006/2/2, Jim Gallacher <[EMAIL PROTECTED]>:
> I know you said no discussi
On 03/02/2006, at 4:48 AM, Daniel J. Popowich wrote:
My gut says any major release of mod_python be based on one
major.minor release lower than the currently available python. So,
mod_python 3.2 is based on python 2.3; mod_python 3.3 will probably be
based on python 2.4 (because 2.5 will be out
According to the Apache rules we need three +1 votes. As there are only
4 of us voting the two +0 votes are already enough to kill the proposal.
(I should have done the math this morning. ;) )
I'll commit Grahams' _conn_read fix and generate the 3.2.7 tarball
shortly. I'm also +1 on releasing
I'm getting a unit test failure.
FAIL: test_publisher_cache (__main__.PerRequestTestCase)
--
Traceback (most recent call last):
File "test.py", line 1836, in test_publisher_cache
self.fail(
File "/usr/lib/python2.3/unitte
I have a bunch of code I was thinking of contributing to mod_python,
but would like some opinions before doing so (because I don't
know if this is the best place)...
Basically I wrote some utility functions which can be used to
assist with content negotiation; such as parsing the various
Accept-*
Daniel J. Popowich wrote ..
> PS
> If it's not obvious I'm gearing up to get way more involved...I've
> been waiting (patiently) for 3.2 to be released and jump in with new
> 3.3 development...I guess I'm chomping at the bit...
We probably want to defer until after 3.2.7 (final) is released to hav
Allow PythonImport to optionally call function in module.
-
Key: MODPYTHON-118
URL: http://issues.apache.org/jira/browse/MODPYTHON-118
Project: mod_python
Type: Wish
Components: core
Versions: 3.3
Graham Dumpleton writes:
> Daniel J. Popowich wrote ..
> > PS
> > If it's not obvious I'm gearing up to get way more involved...I've
> > been waiting (patiently) for 3.2 to be released and jump in with new
> > 3.3 development...I guess I'm chomping at the bit...
>
> We probably want to defer unti
Very interesting. I'll only comment on one issue right now.
Daniel J. Popowich wrote ..
> o And...no suprise...I'd like to try to sell mpservlets for
> inclusion in the main distro. No tears if it's not, but I think
> it fills a void and I'd like to make a case for its inclusion.
I con
Jim Gallacher wrote:
Graham Dumpleton wrote:
Jim Gallacher wrote ..
I'm getting a unit test failure.
FAIL: test_publisher_cache (__main__.PerRequestTestCase)
--
Traceback (most recent call last):
File "test.py", line 1836,
Jim Gallacher wrote ..
> > It is because you probably have a prefork/worker MPM.
> >
> >> The test as written will only reliably work for winnt MPM.
> >
> >
> > Doh! Prefork bites us in the a** yet again. :)
> >
> >> On UNIX boxes
> >> the subsequent requests could be handled by a different c
Graham Dumpleton wrote:
Jim Gallacher wrote ..
It is because you probably have a prefork/worker MPM.
The test as written will only reliably work for winnt MPM.
Doh! Prefork bites us in the a** yet again. :)
On UNIX boxes
the subsequent requests could be handled by a different child pro
Graham Dumpleton wrote:
To confirm Jim's arithmetic anyway, I say -1 on 3.2.6 as it stands.
As to 3.2.7, I say +1, subject to removal of problematic test case
as already raised and with us at least confirming tests run OK for
version out of SVN prior to packaging.
Oh, so *that's* where you sai
We probably want to defer until after 3.2.7 (final) is released to have
any serious discussion about what should constitute version 3.3, but
am still curious to know at this point where your interests in 3.3 lie.
Is it simply to help finish up eliminating all these known issues/bugs
or do you ha
On 03/02/2006, at 2:54 PM, Jim Gallacher wrote:
Graham Dumpleton wrote:
To confirm Jim's arithmetic anyway, I say -1 on 3.2.6 as it stands.
As to 3.2.7, I say +1, subject to removal of problematic test case
as already raised and with us at least confirming tests run OK for
version out of SVN p
21 matches
Mail list logo
