Re: Regex based publisher proposal

2006-09-09 Thread Sébastien Arnaud 

Hi Dan,

I use the Queue class to perform DB pooling, and use 3 different  
types of templating system in various mod_python applications. So  
yes, mod_python makes all those customization very easy and it is why  
I love it as well. The only downside I have found is that after  
developing several applications, maintaining all those custom  
handlers can be daunting, and I just wished that some of this basic  
additional plumbing was avail to some extent in mod_python.


There are also some clear disadvantages of having all mod_python user  
to write their own handler, it is not always that trivial to write  
a robust basic framework that is secure, and thread safe. It also  
seems like an awful waste of time and duplication of efforts, even if  
the learning experience opportunity is great.


Finally, in my current work environment where I advocated the use of  
mod_python, I have found myself in a position where bringing in new  
fresh developers can be a little bit painful, when you have to  
basically start supporting your own custom framework, write  
documentation on its behavior, etc... Anyway, that's partly where my  
motivation came from and hope that others will support the idea.


Thanks,

Sébastien

P.S. I will try WingIDE, I believe I tried it out a while back, but  
under OS X the interface via X11 did not feel quite right and was  
pretty slow if I remember correctly. I'll give it another chance  
though ;)


On Sep 8, 2006, at 9:38 AM, Dan Eloff wrote:


* DB connection pooling


Got that. It's actually very simple. Just derive from the Queue class,
it's already synchronized. Override pop with the logic for handing out
connections. Simply use put to return it when you're done. I recommend
putting the db information in a config file like rails does, nobody
wants to have to put that all over the place.


* Generic rendering template system (empowering the developer to use
virtually ANY templating system avail in python)


That's the way mod_python is as far as I know, it pretty much lets you
do your own thing for templates. Since everyone seems to have
different ideas about what templates they like, I think that's great.


* Remote DB Sessions (for scalability)


Got that for mysql, but is based on a different session model than
mod_python uses. Someone else posted a mysql session here recently, I
do not know what became of it, I would recommend you follow up before
it goes cold.


* Advanced Debugging


Get wingide, I've never seen a better debugger for python. It handles
remote debugging on mod_python flawlessly. When PythonDebug is on, I
automaticaly connect to the debugger from python. I tried Komodo first
for the same, but it is worse than useless. If you want help getting
that working let me know.

-Dan




PGP.sig
Description: This is a digitally signed message part

Re: Regex based publisher proposal

2006-09-07 Thread Sébastien Arnaud 
 system (empowering the developer to use  
virtually ANY templating system avail in python)

* Remote DB Sessions (for scalability)
* Advanced Debugging
* Close integration of apache features exposed by mod_python

Regards,

Sébastien


On Sep 7, 2006, at 1:17 AM, Graham Dumpleton wrote:



On 07/09/2006, at 2:59 PM, Sébastien Arnaud wrote:
Anyway, please share your comments and feedback to make sure I am  
headed in the right direction by keeping in mind that my first  
goal is to be able to publish using a defined regex url grammar a  
callable class within a module. I believe that once this first  
step is accomplished the real design of the web framework can begin.


A few comments while I work out what your code actually does.

class Mapper:
 This is the object to cache the regex engine 
	regex = (?Pcontroller[\w]+)?(\.(?Pextension[\w]+))?(/(? 
Paction[^/]+))?(\?$)?

regex_compared = 0

def __init__(self):
self.reobj = re.compile(self.regex)

def __call__(self, uri, cre):
if(cre!=None and not self.regex_compared and cre!=self.regex):
self.regex = cre
self.reobj = re.compile(self.regex)
self.regex_compared = 1
m = self.reobj.match(uri)
if m:
			return (m.group('controller'), m.group('extension'), m.group 
('action'))

else:
return (None, None, None)

mapper_cache = Mapper()

This is not thread safe and use in a multithreaded MPM, ie., winnt  
and worker, may
result in failure. I also suspect if you would have problems where  
two different parts
of the URL namespace use different regex's and they aren't  
executing in different

Python interpreter instances.

path,module_name =  os.path.split(req.filename)

# Trimming the front part of req.uri
if module_name=='':
req_url = ''
else:
req_url = req.uri[req.uri.index(module_name):]

This is not a very robust way of doing this can technically could  
fail in certain cases.


# Now determine the actual Python module code file
# to load. This will first try looking for the file
# '/path/module_name.py'.
req.filename = path + '/' + controller + '.py'
if not exists(req.filename):
raise apache.SERVER_RETURN, apache.HTTP_NOT_FOUND

I am not really sure why you go to all this trouble. For the way  
the default regex
is written, this could possibly just as easily be achieved using  
standard mod_python.publisher,
using subdirectories in document tree and use of MultiViews  
matching in an appropriate

way.

In other words, am not convinced that your code is required at all  
and you may be
able to achieve the same thing as default regex using standard  
mod_python.publisher.
At worst case, you might need to use Apache RewriteRule. In  
mod_python 3.3, you

could probably do all this with a very simple fixup handler as well.

Thus, as already requested, can you actually supply some examples  
of how this is

used in practice.

BTW, you could also have done this by using a wrapper handler  
around the
existing mod_python.publisher handler as well, thereby avoiding  
having to cut and

paste all the code.

Graham




PGP.sig
Description: This is a digitally signed message part

Re: mod_python 3.2.7 available for testing

2006-02-06 Thread Sébastien Arnaud 

Hi,

I hate to be the first one to report an issue with 3.2.7 tarball...  
It might be related to my lack of knowledge (just joined the dev list  
a few days ago), but here it is:


It is failing during the configure process...

[EMAIL PROTECTED] ~/mod_python-3.2.7 $ ./configure --with-apxs=/usr/ 
sbin/apxs2

checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for ar... ar
checking for a BSD-compatible install... /usr/bin/install -c
checking whether make sets $(MAKE)... yes
checking for main in -lm... yes
checking for an ANSI C-conforming const... yes
checking your blood pressure... a bit high, but we can proceed
configure: checking whether apxs is available...
checking for --with-apxs... /usr/sbin/apxs2 executable, good
checking Apache version... 2.0.55
checking for Apache libexec directory... /usr/lib64/apache2/modules
checking for Apache include directory... -I/usr/include/apache2
checking for --with-python... no
checking for python... /usr/bin/python
checking Python version... 2.4
checking Python install prefix... /usr
checking checking where python libraries are installed... /usr/lib64/ 
python2.4

checking for Py_NewInterpreter in -lpython2.4... yes
checking what libraries Python was linked with... -lpython2.4   - 
lpthread -ldl  -lutil   -lm

checking linker flags used to link Python...
checking where Python include files are... -I/usr/include/python2.4
./configure: line 3427: syntax error near unexpected token `('
./configure: line 3427: `  as_lineno_3=`(expr $as_lineno_1 + 1) 2/ 
dev/null`'


System is an Opteron 170 running Gentoo in 64 bit mode (2005.1 profile):

uname -a
Linux andromeda 2.6.14-gentoo-r5 #1 SMP Sun Jan 15 21:46:56 CST 2006  
x86_64 Dual Core AMD Opteron(tm) Processor 170 AuthenticAMD GNU/Linux


/usr/sbin/apache2 -v
Server version: Apache/2.0.55
Server built:   Jan 19 2006 15:46:57

/usr/sbin/apache2 -l
Compiled in modules:
  core.c
  prefork.c
  http_core.c
  mod_so.c

Python is 2.4.2

FYI, mod_python 3.1.4 configures, compiles and runs fine on the same  
system.


Please let me know if you need anymore info.

Thanks,

Sébastien


On Feb 5, 2006, at 8:10 PM, Jim Gallacher wrote:

Mod_python 3.2.7 tarball is available for test. Here's hoping this  
will be to final time we need your help testing before the official  
release.


3.2.7 adds a fix for the connection read issue that was causing  
problems on FreeBSD.


Here are the rules:

In order for a file to be officially announced, it has to be tested by
developers on the dev list. Anyone subscribed to this list can (and
should feel obligated to :-) ) test it, and provide feedback *to  
_this_

 list*! (Not the [EMAIL PROTECTED] list, and preferably not me
personally).

The files are (temporarily) available here:

http://www.modpython.org/dist/

Please download it, then do the usual

$ ./configure --with-apxs=/wherever/it/is
$ make
$ (su)
# make install

Then (as non-root user!)

$ cd test
$ python test.py

And see if any tests fail. If they pass, send a +1 to the list, if  
they
fail, send the details (the versions of OS, Python and Apache, the  
test

output, and suggestions, if any).

Thank you for your assistance,
Jim Gallacher





PGP.sig
Description: This is a digitally signed message part

Re: mod_python 3.2.7 available for testing

2006-02-06 Thread Sébastien Arnaud 

Hi Graham,

I am using:

[EMAIL PROTECTED] ~/mod_python-3.2.7 $ bash --version
GNU bash, version 3.1.7(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.

I will look at if I can find later the BASH bug you are referring to.  
I had the feeling that it was not directly mod_python causing the  
issue, but that I ought to report the issue, since the problem was  
not existent when I compiled the latest official release of  
mod_python (3.1.4)


Thanks,

Sébastien


On Feb 6, 2006, at 2:06 PM, Graham Dumpleton wrote:

What version of BASH shell are you using? Can't remember the  
version, but a
particular patch level revision of BASH released recently has a bug  
in it
which causes configure to error. Ie., it is a BASH bug and not  
mod_python.


Have to run now, so more later.

Graham

On 07/02/2006, at 6:46 AM, Sébastien Arnaud wrote:


Hi,

I hate to be the first one to report an issue with 3.2.7  
tarball... It might be related to my lack of knowledge (just  
joined the dev list a few days ago), but here it is:


It is failing during the configure process...

[EMAIL PROTECTED] ~/mod_python-3.2.7 $ ./configure --with-apxs=/ 
usr/sbin/apxs2

checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for ar... ar
checking for a BSD-compatible install... /usr/bin/install -c
checking whether make sets $(MAKE)... yes
checking for main in -lm... yes
checking for an ANSI C-conforming const... yes
checking your blood pressure... a bit high, but we can proceed
configure: checking whether apxs is available...
checking for --with-apxs... /usr/sbin/apxs2 executable, good
checking Apache version... 2.0.55
checking for Apache libexec directory... /usr/lib64/apache2/modules
checking for Apache include directory... -I/usr/include/apache2
checking for --with-python... no
checking for python... /usr/bin/python
checking Python version... 2.4
checking Python install prefix... /usr
checking checking where python libraries are installed... /usr/ 
lib64/python2.4

checking for Py_NewInterpreter in -lpython2.4... yes
checking what libraries Python was linked with... -lpython2.4   - 
lpthread -ldl  -lutil   -lm

checking linker flags used to link Python...
checking where Python include files are... -I/usr/include/python2.4
./configure: line 3427: syntax error near unexpected token `('
./configure: line 3427: `  as_lineno_3=`(expr $as_lineno_1 + 1) 2/ 
dev/null`'


System is an Opteron 170 running Gentoo in 64 bit mode (2005.1  
profile):


uname -a
Linux andromeda 2.6.14-gentoo-r5 #1 SMP Sun Jan 15 21:46:56 CST  
2006 x86_64 Dual Core AMD Opteron(tm) Processor 170 AuthenticAMD  
GNU/Linux


/usr/sbin/apache2 -v
Server version: Apache/2.0.55
Server built:   Jan 19 2006 15:46:57

/usr/sbin/apache2 -l
Compiled in modules:
  core.c
  prefork.c
  http_core.c
  mod_so.c

Python is 2.4.2

FYI, mod_python 3.1.4 configures, compiles and runs fine on the  
same system.


Please let me know if you need anymore info.

Thanks,

Sébastien


On Feb 5, 2006, at 8:10 PM, Jim Gallacher wrote:

Mod_python 3.2.7 tarball is available for test. Here's hoping  
this will be to final time we need your help testing before the  
official release.


3.2.7 adds a fix for the connection read issue that was causing  
problems on FreeBSD.


Here are the rules:

In order for a file to be officially announced, it has to be  
tested by

developers on the dev list. Anyone subscribed to this list can (and
should feel obligated to :-) ) test it, and provide feedback *to  
_this_
 list*! (Not the [EMAIL PROTECTED] list, and preferably  
not me

personally).

The files are (temporarily) available here:

http://www.modpython.org/dist/

Please download it, then do the usual

$ ./configure --with-apxs=/wherever/it/is
$ make
$ (su)
# make install

Then (as non-root user!)

$ cd test
$ python test.py

And see if any tests fail. If they pass, send a +1 to the list,  
if they
fail, send the details (the versions of OS, Python and Apache,  
the test

output, and suggestions, if any).

Thank you for your assistance,
Jim Gallacher









PGP.sig
Description: This is a digitally signed message part

Re: bash bug (was Re: mod_python 3.2.7 available for testing)

2006-02-06 Thread Sébastien Arnaud 

Hi,

I would like to report:

+1 Gentoo 2005.1 (amd64), Apache 2.0.55-prefork, Python 2.4.2

After replacing the troubling line (line 3038, configure):

from:
MP_VERSION=`echo $MP_VERSION | sed s/\\//g`
to (Deron's 1st suggestion):
MP_VERSION=`echo $MP_VERSION | sed 's///g' `

I guess now it's up to you to decide if you want to integrate the  
patch or if you want to leave it as is for this release ;)


Thanks,

Sébastien


On Feb 6, 2006, at 4:13 PM, Deron Meranda wrote:


On 2/6/06, Jim Gallacher [EMAIL PROTECTED] wrote:

A couple of thoughts on this issue.

According to the gentoo bug report quoted below, the problem in
configure.in is the double backslash escape sequence in the line:

MP_VERSION=`echo $MP_VERSION | sed s/\\//g`

Changing this to:
MP_VERSION=`echo $MP_VERSION | sed s/\//g`


fixes it for bash 3.1. I wonder why we are using \\ since the gentoo
fix seems to work ok with bash 3.0 (and GNU sed) on my system just as
well. Is it there to support other shells, other sed versions, older
bash versions... ??

I suggest we either adopt the gentoo fix, or avoid the problem
altogether by using tr. eg.

MP_VERSION=`echo $MP_VERSION | tr -d ''`

I'm assuming tr is always available on UNIX-like systems.


Personally I prefer tr because it's more readable. But I don't know
it's availability outside Unix.  You can try single-quoting the sed
expression and eliminationg the backslashes altogether:

  MP_VERSION=`echo $MP_VERSION | sed 's///g' `

If there is also some problem with a sed treating  as a special
character, you can always use character classes:

  MP_VERSION=`echo $MP_VERSION | sed 's/[]//g' `

I generally find that avoid backslashes at all cost improves
portability of scripts across broken shells/seds.
--
Deron Meranda




PGP.sig
Description: This is a digitally signed message part