:
> I haven't said anything because I have been too busy and also because
> this topic has been covered before on the mailing list and it is in the
> archives. The only trick is working out the right search terms to
> find the
> answer. To save you the trouble:
>
> http://www.modpython.org/pipermail/mod_python/2006-April/020867.html
>
> Also see:
>
> http://www.modpython.org/pipermail/mod_python/2006-July/021610.html
>
> Ie. you can always just use Apache LimitRequestBody directive. And:
>
> http://www.modpython.org/pipermail/mod_python/2006-July/021611.html
>
> Ie., used for fixuphandler approach, don't use HTTP_BAD_REQUEST, but
> HTTP_REQUEST_ENTITY_TOO_LARGE. Also see comments about
> length being required.
Thanks for the tips. Based on those posts I produced this fixup handler:
#
# _upload_limit.py
#
from mod_python import apache
UPLOAD_LIMIT = 1 * 1024 * 1024
def fixuphandler(req):
if req.method == 'POST':
length = req.headers_in.get('Content-Length')
if length is None:
req.status = apache.HTTP_LENGTH_REQUIRED
req.log_error('fixupHandler: %s %s' % \
(req.status, 'HTTP_LENGTH_REQUIRED'))
return apache.DONE
elif int(length) > UPLOAD_LIMIT:
req.status = apache.HTTP_REQUEST_ENTITY_TOO_LARGE
req.log_error('fixupHandler: %s %s' % \
(req.status, 'HTTP_REQUEST_ENTITY_TOO_LARGE'))
req.content_type = 'text/html'
html = """\
Failed upload: too large.
Size limit: %s bytes.
Go Back
""" % UPLOAD_LIMIT
req.write(html)
return apache.DONE
return apache.OK
#############################
httpd.conf:
SetHandler mod_python
PythonHandler ~/_publisher.py
PythonOption mod_python.importer.path "['~/mod']"
PythonFixupHandler _upload_limit
BTW apache.DONE is not documented in the current manual. This Google
search returns nothing:
apache.DONE site:modpython.org/live/current/doc-html/
Regards,
--
Clodoaldo Pinto Neto
From grahamd at dscpl.com.au Sat Feb 3 22:41:18 2007
From: grahamd at dscpl.com.au (Graham Dumpleton)
Date: Sat Feb 3 22:41:33 2007
Subject: [mod_python] in modpython ,how to restrict the upload file size?
In-Reply-To:
References:
<2612593E-9AAA-4D5C-9193-360FAE375731@dscpl.com.au>
Message-ID:
On 04/02/2007, at 12:41 AM, Clodoaldo wrote:
>
> BTW apache.DONE is not documented in the current manual. This Google
> search returns nothing:
> apache.DONE site:modpython.org/live/current/doc-html/
It gets a bit more of a mention in 3.3 documentation, although still
not enough. :-)
Try:
apache.DONE inurl:doc-html site:www.modpython.org
as the search term.
Returning apache.DONE rather than apache.OK in a phase prevents
latter phases
from being run. The idea is it indicates that that phase has been
able to return a
complete response and therefore there is no need to go further.
Graham
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20070204/24a1ba67/attachment.html
From grahamd at dscpl.com.au Sat Feb 3 23:00:32 2007
From: grahamd at dscpl.com.au (Graham Dumpleton)
Date: Sat Feb 3 23:00:43 2007
Subject: [mod_python] utf-8 encoding - still a problem
In-Reply-To: <45C3B205.24633.1E12B04@export.hope.cz>
References: <45C3B205.24633.1E12B04@export.hope.cz>
Message-ID:
On 03/02/2007, at 7:49 AM, export@hope.cz wrote:
> Thank you all who recently offered a solution to my UTF-8 problem.
> So I added to my handler
>
> req.content_type = 'text/html ;charset=utf-8'
> req.write('''
> ....
> ...
>
> ...
> (""".decode('utf8').encode('utf8'))
>
> But now when I try to call handler
> like http://www..../mod/uploadvideo.py?24795
> a download dialog is presented as if I wanted to download that script.
>
> But If I do NOT use
> charset=utf-8 in req.content_type
> the script works good( except NOT utf-8 coding).and no download
> dialog is shown.
> Where can be a problem?
Does it still fail if you take out the space before the semicolon?
Maybe your
web client is being very fussy.
Have you tried to use some means to look at the headers sent back by
mod_python in the response to verify what has actually been sent? There
are extensions to firefox to look at headers returned, but I think
you can
also use tools like wget/curl to remember headers so you can look at
them
as well.
Graham
From jpg at jgassociates.ca Sun Feb 4 12:28:08 2007
From: jpg at jgassociates.ca (Jim Gallacher)
Date: Sun Feb 4 12:22:33 2007
Subject: [mod_python] utf-8 encoding - still a problem
In-Reply-To:
References: <45C3B205.24633.1E12B04@export.hope.cz>
Message-ID: <45C617A8.7010807@jgassociates.ca>
Graham Dumpleton wrote:
>
> On 03/02/2007, at 7:49 AM, export@hope.cz wrote:
>
>> Thank you all who recently offered a solution to my UTF-8 problem.
>> So I added to my handler
>>
>> req.content_type = 'text/html ;charset=utf-8'
>> req.write('''
>> ....
>> ...
>>
>> ...
>> (""".decode('utf8').encode('utf8'))
>>
>> But now when I try to call handler
>> like http://www..../mod/uploadvideo.py?24795
>> a download dialog is presented as if I wanted to download that script.
>>
>> But If I do NOT use
>> charset=utf-8 in req.content_type
>> the script works good( except NOT utf-8 coding).and no download dialog
>> is shown.
>> Where can be a problem?
>
> Does it still fail if you take out the space before the semicolon? Maybe
> your
> web client is being very fussy.
>
> Have you tried to use some means to look at the headers sent back by
> mod_python in the response to verify what has actually been sent? There
> are extensions to firefox to look at headers returned,
I find the Web Developer extension to be handy for this and so much
more. See https://addons.mozilla.org/firefox/60/
> but I think you can
> also use tools like wget/curl to remember headers so you can look at them
> as well.
wget should be in everyone's toolkit.
Jim
From export at hope.cz Mon Feb 5 02:09:41 2007
From: export at hope.cz (export@hope.cz)
Date: Mon Feb 5 02:09:53 2007
Subject: [mod_python] utf-8 encoding -soved
In-Reply-To:
References: <45C3B205.24633.1E12B04@export.hope.cz>
Message-ID: <45C6E645.28009.83DDB89@export.hope.cz>
An HTML attachment was scrubbed...
URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20070205/a6ab4fab/attachment.html
From hayat221 at yahoo.com Mon Feb 5 08:31:55 2007
From: hayat221 at yahoo.com (sikander hayat)
Date: Mon Feb 5 08:32:01 2007
Subject: [mod_python] integrate mod_python and mod_python servlets
In-Reply-To:
Message-ID: <20070205133155.74687.qmail@web38709.mail.mud.yahoo.com>
Hi all,
I m quite new to mod_python and was wondering if there is a way to incorporate both mod_python publisher handler (to perform actual program logic, written in .py file) and then use mod_python servlet handler to display the dynamic page on an apache webserver.
To be more clear:
I have a .py program that performs some logic. ()
how can i use this existing python file (conforming to mod_python) and then use servlet handler to generate a dynamic webpage.
Thanks,
Sikander Hayat
---------------------------------
Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20070205/c8777581/attachment.html
From labs at ixopusada.com Tue Feb 6 11:56:31 2007
From: labs at ixopusada.com (Dirk van Oosterbosch, IR labs)
Date: Tue Feb 6 11:56:38 2007
Subject: [mod_python] PythonPath and importer in 3.3
Message-ID:
Hi,
I am not sure if this the right list to ask, since 3.3 is still in
beta, but after reading the documentation about PythonPath and
import_module I'm running into problems as I try to follow the
directions expressed in the documentation.
First off, let me state that when I upgraded to mod_python 3.3, I was
happily surprised that everything just worked like before, with only
changes visible in the log file. However, as I tried to fix something
(PythonPath and importing modules) which didn't seem to cause
problems, things broke down and I can't get them to work according to
the docs.
"Why trying to fix it then, when there was no problem?", you ask.
Good question ;-)
My initial setup was like this:
in httpd.conf:
====================
PythonPath "sys.path + ['/Users/me/Sites/www/python/']"
PythonTransHandler translate
...
in the .htaccess file in .../www/python/:
====================
AddHandler mod_python .py
PythonHandler main
Then in main.py (the main handler which is called for every request):
====================
# for loading a Cheetah template
templatesFolderLocation = "/Users/me/Sites/www/python/templates"
if templatesFolderLocation not in sys.path:
sys.path.append(templatesFolderLocation)
...
modulename = 'page'
...
try:
module = __import__(modulename, globals(), locals(), [modulename])
except ImportError:
...
templateClass = getattr(module, name)
As said, this code works. Though it is not very nice and clean, and I
understood I had to go this way, while I was waiting for mod_python
3.3. Now I got python 3.3 and I read the documentation about
apache.import_module() and about PythonPath, and I want to change the
code so it will make proper use of the new importer.
The first thing I noticed in the docs is that the PythonPath
shouldn't contain paths which are in the document tree.
http://www.modpython.org/live/mod_python-3.3.0b/doc-html/app-changes-
from-3.2.10.html :
> The PythonPath directive MUST not be used to point at directories
> within the document tree.
So I changed the PythonPath line in httpd.conf into
PythonOption mod_python.importer.path "['/Users/dirk/Sites/www/
python']"
But ?as somewhat expected? this breaks the Cheetah module importing
code.
I tried to change it according to the docs
(these http://www.modpython.org/live/mod_python-3.3.0b/doc-html/pyapi-
apmeth.html )
So now the code in main.py looks like this:
====================
# for loading a Cheetah template
templatesFolderLocation = "/Users/me/Sites/www/python/templates"
# not appending to sys.path anymore
...
modulename = 'page'
...
try:
module = apache.import_module(modulename, path=
[templatesFolderLocation])
except ImportError:
... # importing the module fails here!
templateClass = getattr(module, name)
The reason for the failing import seems to be the inheritance system
of the templates. Inside the chain of Cheetah modules that are
inheriting eachother, there is a pure python module (framework.py),
residing in /www/python (not in /www/python/templates/ !) which tries
to import a module from /www/python/templates/ through this line:
from baseTemplate import baseTemplate
I believe this fails and is the origin of my new problem.
I thought the module search path, which I supplied with the path=
argument in import_module() was copied forward to all subsequent
imports, but it seems this does not work for me.
Now I would be happy to add the templates directory to the python
path again, but as I understood this is not the proper new mod_python
way.
However I am reluctant to change the importing mechanism in
framework.py and make framework dependant on mod_python's apache,
since I also want to be able to test the cheetah part of my system
outside of apache.
I hope I am missing something obvious. What would be the most clean
and proper way to solve this issue?
Thanks!
dirk
-----------------------------
Dirk van Oosterbosch
de Wittenstraat 225
1052 AT Amsterdam
the Netherlands
http://labs.ixopusada.com
-----------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20070206/f462ef3b/attachment.html
From jpg at jgassociates.ca Tue Feb 6 12:29:30 2007
From: jpg at jgassociates.ca (Jim Gallacher)
Date: Tue Feb 6 12:27:21 2007
Subject: [mod_python] PythonPath and importer in 3.3
In-Reply-To:
References:
Message-ID: <45C8BAFA.5080708@jgassociates.ca>
Dirk van Oosterbosch, IR labs wrote:
> Hi,
>
> I am not sure if this the right list to ask, since 3.3 is still in beta,
> but after reading the documentation about PythonPath and import_module
> I'm running into problems as I try to follow the directions expressed in
> the documentation.
3.3 is out of beta and will be released as 3.3.1. There are no changes
from 3.3.0b except the version strings. We're just waiting for Grisha to
make the official announcement.
Graham is the guy that really understands the new importer, but he is
heading off on holiday (or may in fact already be gone). In the worst
case scenario you can revert to the 3.2.10 importer behaviour by using
the following directive:
PythonOption mod_python.legacy.importer *
Hopefully we can muddle through before Graham gets back, but at least
you won't be completely stuck.
I have no time to investigate right now but I'll try to take a look tonight.
Jim
> First off, let me state that when I upgraded to mod_python 3.3, I was
> happily surprised that everything just worked like before, with only
> changes visible in the log file. However, as I tried to fix something
> (PythonPath and importing modules) which didn't seem to cause problems,
> things broke down and I can't get them to work according to the docs.
> "Why trying to fix it then, when there was no problem?", you ask. Good
> question ;-)
>
> My initial setup was like this:
> in httpd.conf:
> ====================
>
> PythonPath "sys.path + ['/Users/me/Sites/www/python/']"
> PythonTransHandler translate
> ...
>
> in the .htaccess file in .../www/python/:
> ====================
> AddHandler mod_python .py
> PythonHandler main
>
> Then in main.py (the main handler which is called for every request):
> ====================
> # for loading a Cheetah template
> templatesFolderLocation = "/Users/me/Sites/www/python/templates"
> if templatesFolderLocation not in sys.path:
> sys.path.append(templatesFolderLocation)
> ...
> modulename = 'page'
> ...
> try:
> module = __import__(modulename, globals(), locals(), [modulename])
> except ImportError:
> ...
> templateClass = getattr(module, name)
>
>
> As said, this code works. Though it is not very nice and clean, and I
> understood I had to go this way, while I was waiting for mod_python 3.3.
> Now I got python 3.3 and I read the documentation about
> apache.import_module() and about PythonPath, and I want to change the
> code so it will make proper use of the new importer.
>
> The first thing I noticed in the docs is that the PythonPath shouldn't
> contain paths which are in the document tree.
> http://www.modpython.org/live/mod_python-3.3.0b/doc-html/app-changes-from-3.2.10.html
> :
>> The PythonPath directive MUST not be used to point at directories
>> within the document tree.
>
> So I changed the PythonPath line in httpd.conf into
> PythonOption mod_python.importer.path
> "['/Users/dirk/Sites/www/python']"
>
> But ?as somewhat expected? this breaks the Cheetah module importing code.
> I tried to change it according to the docs
> (these
> http://www.modpython.org/live/mod_python-3.3.0b/doc-html/pyapi-apmeth.html
> )
>
> So now the code in main.py looks like this:
> ====================
> # for loading a Cheetah template
> templatesFolderLocation = "/Users/me/Sites/www/python/templates"
> # not appending to sys.path anymore
> ...
> modulename = 'page'
> ...
> try:
> module = apache.import_module(modulename,
> path=[templatesFolderLocation])
> except ImportError:
> ... # importing the module fails here!
> templateClass = getattr(module, name)
>
>
> The reason for the failing import seems to be the inheritance system of
> the templates. Inside the chain of Cheetah modules that are inheriting
> eachother, there is a pure python module (framework.py), residing in
> /www/python (not in /www/python/templates/ !) which tries to import a
> module from /www/python/templates/ through this line:
> from baseTemplate import baseTemplate
> I believe this fails and is the origin of my new problem.
>
> I thought the module search path, which I supplied with the path=
> argument in import_module() was copied forward to all subsequent
> imports, but it seems this does not work for me.
>
> Now I would be happy to add the templates directory to the python path
> again, but as I understood this is not the proper new mod_python way.
> However I am reluctant to change the importing mechanism in framework.py
> and make framework dependant on mod_python's apache, since I also want
> to be able to test the cheetah part of my system outside of apache.
>
> I hope I am missing something obvious. What would be the most clean and
> proper way to solve this issue?
>
> Thanks!
> dirk
>
>
>
>
>
> -----------------------------
> Dirk van Oosterbosch
> de Wittenstraat 225
> 1052 AT Amsterdam
> the Netherlands
>
> http://labs.ixopusada.com
> -----------------------------
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mod_python mailing list
> Mod_python@modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python
From martijn at xs4us.nu Tue Feb 6 13:19:07 2007
From: martijn at xs4us.nu (Martijn Moeling)
Date: Tue Feb 6 13:19:20 2007
Subject: [mod_python] PythonPath and importer in 3.3
Message-ID:
I remember that there is a new directive to tell python/MP where the
modules are, sys.path should NOT be included, I looked it up in my
config and you should set the following line in your GLOBAL apache
config
PythonOption mod_python.importer.path ["/Users/me/Sites/www/python/"]
The pythonPath works with the old importer, and the above is Used in the
new 3.3 Importer
That should do the job for you...
Let me know if there are more questions
Martijn
(I am trying to contribute as much as I can to help, especially whilst
Graham is away, I am a havy 3.3 user, but don't know everything either)
-----Oorspronkelijk bericht-----
Van: mod_python-bounces@modpython.org
[mailto:mod_python-bounces@modpython.org] Namens Jim Gallacher
Verzonden: Tuesday, February 06, 2007 18:30
Aan: Dirk van Oosterbosch, IR labs
CC: mod_python list
Onderwerp: Re: [mod_python] PythonPath and importer in 3.3
Dirk van Oosterbosch, IR labs wrote:
> Hi,
>
> I am not sure if this the right list to ask, since 3.3 is still in
beta,
> but after reading the documentation about PythonPath and import_module
> I'm running into problems as I try to follow the directions expressed
in
> the documentation.
3.3 is out of beta and will be released as 3.3.1. There are no changes
from 3.3.0b except the version strings. We're just waiting for Grisha to
make the official announcement.
Graham is the guy that really understands the new importer, but he is
heading off on holiday (or may in fact already be gone). In the worst
case scenario you can revert to the 3.2.10 importer behaviour by using
the following directive:
PythonOption mod_python.legacy.importer *
Hopefully we can muddle through before Graham gets back, but at least
you won't be completely stuck.
I have no time to investigate right now but I'll try to take a look
tonight.
Jim
> First off, let me state that when I upgraded to mod_python 3.3, I was
> happily surprised that everything just worked like before, with only
> changes visible in the log file. However, as I tried to fix something
> (PythonPath and importing modules) which didn't seem to cause
problems,
> things broke down and I can't get them to work according to the docs.
> "Why trying to fix it then, when there was no problem?", you ask. Good
> question ;-)
>
> My initial setup was like this:
> in httpd.conf:
> ====================
>
> PythonPath "sys.path + ['/Users/me/Sites/www/python/']"
> PythonTransHandler translate
> ...
>
> in the .htaccess file in .../www/python/:
> ====================
> AddHandler mod_python .py
> PythonHandler main
>
> Then in main.py (the main handler which is called for every request):
> ====================
> # for loading a Cheetah template
> templatesFolderLocation = "/Users/me/Sites/www/python/templates"
> if templatesFolderLocation not in sys.path:
> sys.path.append(templatesFolderLocation)
> ...
> modulename = 'page'
> ...
> try:
> module = __import__(modulename, globals(), locals(), [modulename])
> except ImportError:
> ...
> templateClass = getattr(module, name)
>
>
> As said, this code works. Though it is not very nice and clean, and I
> understood I had to go this way, while I was waiting for mod_python
3.3.
> Now I got python 3.3 and I read the documentation about
> apache.import_module() and about PythonPath, and I want to change the
> code so it will make proper use of the new importer.
>
> The first thing I noticed in the docs is that the PythonPath shouldn't
> contain paths which are in the document tree.
>
http://www.modpython.org/live/mod_python-3.3.0b/doc-html/app-changes-fro
m-3.2.10.html
> :
>> The PythonPath directive MUST not be used to point at directories
>> within the document tree.
>
> So I changed the PythonPath line in httpd.conf into
> PythonOption mod_python.importer.path
> "['/Users/dirk/Sites/www/python']"
>
> But -as somewhat expected- this breaks the Cheetah module importing
code.
> I tried to change it according to the docs
> (these
>
http://www.modpython.org/live/mod_python-3.3.0b/doc-html/pyapi-apmeth.ht
ml
> )
>
> So now the code in main.py looks like this:
> ====================
> # for loading a Cheetah template
> templatesFolderLocation = "/Users/me/Sites/www/python/templates"
> # not appending to sys.path anymore
> ...
> modulename = 'page'
> ...
> try:
> module = apache.import_module(modulename,
> path=[templatesFolderLocation])
> except ImportError:
> ... # importing the module fails here!
> templateClass = getattr(module, name)
>
>
> The reason for the failing import seems to be the inheritance system
of
> the templates. Inside the chain of Cheetah modules that are inheriting
> eachother, there is a pure python module (framework.py), residing in
> /www/python (not in /www/python/templates/ !) which tries to import a
> module from /www/python/templates/ through this line:
> from baseTemplate import baseTemplate
> I believe this fails and is the origin of my new problem.
>
> I thought the module search path, which I supplied with the path=
> argument in import_module() was copied forward to all subsequent
> imports, but it seems this does not work for me.
>
> Now I would be happy to add the templates directory to the python path
> again, but as I understood this is not the proper new mod_python way.
> However I am reluctant to change the importing mechanism in
framework.py
> and make framework dependant on mod_python's apache, since I also want
> to be able to test the cheetah part of my system outside of apache.
>
> I hope I am missing something obvious. What would be the most clean
and
> proper way to solve this issue?
>
> Thanks!
> dirk
>
>
>
>
>
> -----------------------------
> Dirk van Oosterbosch
> de Wittenstraat 225
> 1052 AT Amsterdam
> the Netherlands
>
> http://labs.ixopusada.com
> -----------------------------
>
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> Mod_python mailing list
> Mod_python@modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python
_______________________________________________
Mod_python mailing list
Mod_python@modpython.org
http://mailman.modpython.org/mailman/listinfo/mod_python
From grahamd at dscpl.com.au Tue Feb 6 15:11:07 2007
From: grahamd at dscpl.com.au (Graham Dumpleton)
Date: Tue Feb 6 15:11:14 2007
Subject: [mod_python] PythonPath and importer in 3.3
Message-ID: <1170792667.18875@dscpl.user.openhosting.com>
Very quickly as plane goes in about an hour..... :-)
See comments below.
Dirk van Oosterbosch, IR labs wrote ..
> Hi,
>
> I am not sure if this the right list to ask, since 3.3 is still in
> beta, but after reading the documentation about PythonPath and
> import_module I'm running into problems as I try to follow the
> directions expressed in the documentation.
>
> First off, let me state that when I upgraded to mod_python 3.3, I was
> happily surprised that everything just worked like before, with only
> changes visible in the log file. However, as I tried to fix something
> (PythonPath and importing modules) which didn't seem to cause
> problems, things broke down and I can't get them to work according to
> the docs.
> "Why trying to fix it then, when there was no problem?", you ask.
> Good question ;-)
>
> My initial setup was like this:
> in httpd.conf:
> ====================
>
> PythonPath "sys.path + ['/Users/me/Sites/www/python/']"
> PythonTransHandler translate
> ...
>
> in the .htaccess file in .../www/python/:
> ====================
> AddHandler mod_python .py
> PythonHandler main
>
> Then in main.py (the main handler which is called for every request):
> ====================
> # for loading a Cheetah template
> templatesFolderLocation = "/Users/me/Sites/www/python/templates"
> if templatesFolderLocation not in sys.path:
> sys.path.append(templatesFolderLocation)
> ...
> modulename = 'page'
> ...
> try:
> module = __import__(modulename, globals(), locals(), [modulename])
> except ImportError:
> ...
> templateClass = getattr(module, name)
>
>
> As said, this code works. Though it is not very nice and clean, and I
> understood I had to go this way, while I was waiting for mod_python
> 3.3. Now I got python 3.3 and I read the documentation about
> apache.import_module() and about PythonPath, and I want to change the
> code so it will make proper use of the new importer.
>
> The first thing I noticed in the docs is that the PythonPath
> shouldn't contain paths which are in the document tree.
This is only really an issue if the modules in the directory in the
document tree are being imported directly by mod_python importer
by reference in Python*Handler, by mod_python.publisher or by
direct use by apache.import_module(). If the modules in said
directory aren't being included in this way, it is okay to list
a subdirectory somewhere in the document tree in PythonPath.
The important thing is that you want to avoid having modules imported
through both mechanisms.
One step to ensure that anything in a directory isn't used by mod_python
in some way inadvertantly by mod_python.publisher, is to add into the
directory a .htaccess file containing:
deny from all
If using own handler, not so big a deal.
I have managed to get Cheetah to use mod_python importer from within its
generated code before. The trick is to use import_module() instead of
__import__ to import the Cheetah template top level code file.
Ie., don't use:
module = __import__(modulename, globals(), locals(), [modulename])
use:
module = apache.import_module('/actual/path.py')
Then have the templates directory in:
PythonOption mod_python.importer.path ['/actual/path/to/templates']
Try playing with that. If after my nine hour flight to next airport
I find some free internet access, I'll have a look to see how you went.
Anyway, hope I didn't muddle that because of being in a hurry.
:-) :-) :-) :-)
Graham
> http://www.modpython.org/live/mod_python-3.3.0b/doc-html/app-changes-
> from-3.2.10.html :
> > The PythonPath directive MUST not be used to point at directories
> > within the document tree.
>
> So I changed the PythonPath line in httpd.conf into
> PythonOption mod_python.importer.path "['/Users/dirk/Sites/www/
> python']"
>
> But –as somewhat expected– this breaks the Cheetah module importing
> code.
> I tried to change it according to the docs
> (these http://www.modpython.org/live/mod_python-3.3.0b/doc-html/pyapi-
> apmeth.html )
>
> So now the code in main.py looks like this:
> ====================
> # for loading a Cheetah template
> templatesFolderLocation = "/Users/me/Sites/www/python/templates"
> # not appending to sys.path anymore
> ...
> modulename = 'page'
> ...
> try:
> module = apache.import_module(modulename, path=
> [templatesFolderLocation])
> except ImportError:
> ... # importing the module fails here!
> templateClass = getattr(module, name)
>
>
> The reason for the failing import seems to be the inheritance system
> of the templates. Inside the chain of Cheetah modules that are
> inheriting eachother, there is a pure python module (framework.py),
> residing in /www/python (not in /www/python/templates/ !) which tries
> to import a module from /www/python/templates/ through this line:
> from baseTemplate import baseTemplate
> I believe this fails and is the origin of my new problem.
>
> I thought the module search path, which I supplied with the path=
> argument in import_module() was copied forward to all subsequent
> imports, but it seems this does not work for me.
>
> Now I would be happy to add the templates directory to the python
> path again, but as I understood this is not the proper new mod_python
> way.
> However I am reluctant to change the importing mechanism in
> framework.py and make framework dependant on mod_python's apache,
> since I also want to be able to test the cheetah part of my system
> outside of apache.
>
> I hope I am missing something obvious. What would be the most clean
> and proper way to solve this issue?
>
> Thanks!
> dirk
>
>
>
>
>
> -----------------------------
> Dirk van Oosterbosch
> de Wittenstraat 225
> 1052 AT Amsterdam
> the Netherlands
>
> http://labs.ixopusada.com
> -----------------------------
From grahamd at dscpl.com.au Tue Feb 6 15:50:07 2007
From: grahamd at dscpl.com.au (Graham Dumpleton)
Date: Tue Feb 6 15:50:45 2007
Subject: [mod_python] PythonPath and importer in 3.3
Message-ID: <1170795007.3874@dscpl.user.openhosting.com>
Delayed boarding ...
Reading again I see you already did what I was saying, I think though
you just need to list both directories in new import path.
PythonOption mod_python.importer.path ["/Users/me/Sites/www/python/","/Users/me/Sites/www/python/templates"]
The 'path' argument to import_module isn't inherited down. For a
module import by name, only used for top level module search, not
child module imports from that module. The 'path' only gets embedded
in top level module where absolute path for module and not module
name used. Again, this is not passed down through to child imports,
you would need to do that manually by passing __mp_path__ down to
import_module() as described in documentation. This will be no good
in your case because Cheetah generates 'import'.
BTW, where is framework.py. Is it in your '.../www.python' directory
and thus would it be getting imported by mod_python importer even if
by 'import' rather than import_module()? If it is, that it may be
using 'import' should be okay.
Look at the log files to see when stuff is being imported by mod_python
as opposed to getting pushed onto Python itself.
Anyway, plane now loading so have to go.
If you still can't get it going explain the chain of imports including
framework.py, where the files are located and how they are being
imported if you didn't fully already.
Bye.
Graham
Graham Dumpleton wrote ..
> Very quickly as plane goes in about an hour..... :-)
>
> See comments below.
>
> Dirk van Oosterbosch, IR labs wrote ..
> > Hi,
> >
> > I am not sure if this the right list to ask, since 3.3 is still in
> > beta, but after reading the documentation about PythonPath and
> > import_module I'm running into problems as I try to follow the
> > directions expressed in the documentation.
> >
> > First off, let me state that when I upgraded to mod_python 3.3, I was
> > happily surprised that everything just worked like before, with only
> > changes visible in the log file. However, as I tried to fix something
> > (PythonPath and importing modules) which didn't seem to cause
> > problems, things broke down and I can't get them to work according to
> > the docs.
> > "Why trying to fix it then, when there was no problem?", you ask.
> > Good question ;-)
> >
> > My initial setup was like this:
> > in httpd.conf:
> > ====================
> >
> > PythonPath "sys.path + ['/Users/me/Sites/www/python/']"
> > PythonTransHandler translate
> > ...
> >
> > in the .htaccess file in .../www/python/:
> > ====================
> > AddHandler mod_python .py
> > PythonHandler main
> >
> > Then in main.py (the main handler which is called for every request):
> > ====================
> > # for loading a Cheetah template
> > templatesFolderLocation = "/Users/me/Sites/www/python/templates"
> > if templatesFolderLocation not in sys.path:
> > sys.path.append(templatesFolderLocation)
> > ...
> > modulename = 'page'
> > ...
> > try:
> > module = __import__(modulename, globals(), locals(), [modulename])
> > except ImportError:
> > ...
> > templateClass = getattr(module, name)
> >
> >
> > As said, this code works. Though it is not very nice and clean, and I
> > understood I had to go this way, while I was waiting for mod_python
> > 3.3. Now I got python 3.3 and I read the documentation about
> > apache.import_module() and about PythonPath, and I want to change the
> > code so it will make proper use of the new importer.
> >
> > The first thing I noticed in the docs is that the PythonPath
> > shouldn't contain paths which are in the document tree.
>
> This is only really an issue if the modules in the directory in the
> document tree are being imported directly by mod_python importer
> by reference in Python*Handler, by mod_python.publisher or by
> direct use by apache.import_module(). If the modules in said
> directory aren't being included in this way, it is okay to list
> a subdirectory somewhere in the document tree in PythonPath.
>
> The important thing is that you want to avoid having modules imported
> through both mechanisms.
>
> One step to ensure that anything in a directory isn't used by mod_python
> in some way inadvertantly by mod_python.publisher, is to add into the
> directory a .htaccess file containing:
>
> deny from all
>
> If using own handler, not so big a deal.
>
> I have managed to get Cheetah to use mod_python importer from within its
> generated code before. The trick is to use import_module() instead of
> __import__ to import the Cheetah template top level code file.
>
> Ie., don't use:
>
> module = __import__(modulename, globals(), locals(), [modulename])
>
> use:
>
> module = apache.import_module('/actual/path.py')
>
> Then have the templates directory in:
>
> PythonOption mod_python.importer.path ['/actual/path/to/templates']
>
> Try playing with that. If after my nine hour flight to next airport
> I find some free internet access, I'll have a look to see how you went.
>
> Anyway, hope I didn't muddle that because of being in a hurry.
>
> :-) :-) :-) :-)
>
> Graham
>
>
> > http://www.modpython.org/live/mod_python-3.3.0b/doc-html/app-changes-
> > from-3.2.10.html :
> > > The PythonPath directive MUST not be used to point at directories
> > > within the document tree.
> >
> > So I changed the PythonPath line in httpd.conf into
> > PythonOption mod_python.importer.path "['/Users/dirk/Sites/www/
> > python']"
> >
> > But –as somewhat expected– this breaks the Cheetah module
> importing
> > code.
> > I tried to change it according to the docs
> > (these http://www.modpython.org/live/mod_python-3.3.0b/doc-html/pyapi-
> > apmeth.html )
> >
> > So now the code in main.py looks like this:
> > ====================
> > # for loading a Cheetah template
> > templatesFolderLocation = "/Users/me/Sites/www/python/templates"
> > # not appending to sys.path anymore
> > ...
> > modulename = 'page'
> > ...
> > try:
> > module = apache.import_module(modulename, path=
> > [templatesFolderLocation])
> > except ImportError:
> > ... # importing the module fails here!
> > templateClass = getattr(module, name)
> >
> >
> > The reason for the failing import seems to be the inheritance system
> > of the templates. Inside the chain of Cheetah modules that are
> > inheriting eachother, there is a pure python module (framework.py),
> > residing in /www/python (not in /www/python/templates/ !) which tries
> > to import a module from /www/python/templates/ through this line:
> > from baseTemplate import baseTemplate
> > I believe this fails and is the origin of my new problem.
> >
> > I thought the module search path, which I supplied with the path=
> > argument in import_module() was copied forward to all subsequent
> > imports, but it seems this does not work for me.
> >
> > Now I would be happy to add the templates directory to the python
> > path again, but as I understood this is not the proper new mod_python
> > way.
> > However I am reluctant to change the importing mechanism in
> > framework.py and make framework dependant on mod_python's apache,
> > since I also want to be able to test the cheetah part of my system
> > outside of apache.
> >
> > I hope I am missing something obvious. What would be the most clean
> > and proper way to solve this issue?
> >
> > Thanks!
> > dirk
> >
> >
> >
> >
> >
> > -----------------------------
> > Dirk van Oosterbosch
> > de Wittenstraat 225
> > 1052 AT Amsterdam
> > the Netherlands
> >
> > http://labs.ixopusada.com
> > -----------------------------
> _______________________________________________
> Mod_python mailing list
> Mod_python@modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python
From labs at ixopusada.com Tue Feb 6 18:00:40 2007
From: labs at ixopusada.com (Dirk van Oosterbosch, IR labs)
Date: Tue Feb 6 18:01:38 2007
Subject: [mod_python] PythonPath and importer in 3.3
In-Reply-To: <1170795007.3874@dscpl.user.openhosting.com>
References: <1170795007.3874@dscpl.user.openhosting.com>
Message-ID: <8BF7174D-F320-4A20-B39E-8AC6795217BC@ixopusada.com>
Thanks for the quick response, guys.
especially Graham! I certainly don't want to deprive you from your
holiday mood. So, if you're still reading this, clap down your laptop
and enjoy the sun!
> I think you just need to list both directories in new import path.
>
> PythonOption mod_python.importer.path ["/Users/me/Sites/www/
> python/","/Users/me/Sites/www/python/templates"]
( PythonOption mod_python.importer.path "['/Users/me/Sites/www/
python', '/Users/me/Sites/www/python/templates']"
as I understood it needed extra quotes on the outside.)
Indeed. This solves the problem I had.
Then using
module = apache.import_module(template_name)
works and also everything in the chain of inheritance gets loaded
(and shows up in the log!)
However, I am not sure I am 100% happy with adding the path to the
templates directory to the directive in httpd.conf. I rather add the
extra module-search-directories in the hander module (main.py in my
case) itself, possibly determining which directory is extra needed,
based on the request. Is there a function to add to the importer path
from a module itself?
> BTW, where is framework.py. Is it in your '.../www.python' directory
> and thus would it be getting imported by mod_python importer even if
> by 'import' rather than import_module()? If it is, that it may be
> using 'import' should be okay.
Well, the problem wasn't with importing framework.py. I think I
explained it a bit lousy. The problem was with the import statement
*inside* framework.py. My Cheetah inheritance system works like this:
[...]/www/python/templates/specialized_item.tmpl (compiled into .py)
[...]/www/python/templates/page.tmpl (compiled into .py)
[...]/www/python/framework.py
[...]/www/python/templates/FrameworkViewComponents.tmpl (compiled
into .py)
[...]/www/python/templates/BaseSkeleton.tmpl (compiled into .py)
in which specialized_item.tmpl is the first one in the inheritance
chain, being loaded with apache.import_module() and in which
BaseSkeleton.tmpl is my base class Cheetah template.
The problem was the line
from FrameworkViewComponents import FrameworkViewComponents
in framework.py, but this is now solved with the extended
PythonOption directive in httpd.conf.
Nevertheless, another, *minor* problem popped up, which didn't pop up
before:
I also have a template called image.tmpl (and compiled image.py) in
[...]/templates/
Now, with MP3.3 this gives a problem when using the Python Image
Library (PIL) and Image.py Unfortunately the importer cannot
discriminate between image.py and Image.py. Is there a way to
explicitly call python import function and have it search only the
PythonPath? (i.e. *not* the mp importer path first?)
Otherwise I'll have to rename the template, no biggie.
Finally, especially addressing Graham: please don't let these issues
trouble your mind in any way. Happy holidays!
And thanks a lot for all the response,
dirk
>>>
>>> My initial setup was like this:
>>> in httpd.conf:
>>> ====================
>>>
>>> PythonPath "sys.path + ['/Users/me/Sites/www/python/']"
>>> PythonTransHandler translate
>>> ...
>>>
>>> in the .htaccess file in .../www/python/:
>>> ====================
>>> AddHandler mod_python .py
>>> PythonHandler main
>>>
>>> Then in main.py (the main handler which is called for every
>>> request):
>>> ====================
>>> # for loading a Cheetah template
>>> templatesFolderLocation = "/Users/me/Sites/www/python/templates"
>>> if templatesFolderLocation not in sys.path:
>>> sys.path.append(templatesFolderLocation)
>>> ...
>>> modulename = 'page'
>>> ...
>>> try:
>>> module = __import__(modulename, globals(), locals(), [modulename])
>>> except ImportError:
>>> ...
>>> templateClass = getattr(module, name)
>>>
>>>
>>> As said, this code works. Though it is not very nice and clean,
>>> and I
>>> understood I had to go this way, while I was waiting for mod_python
>>> 3.3. Now I got python 3.3 and I read the documentation about
>>> apache.import_module() and about PythonPath, and I want to change
>>> the
>>> code so it will make proper use of the new importer.
>>>
>>> The first thing I noticed in the docs is that the PythonPath
>>> shouldn't contain paths which are in the document tree.
>>
>> This is only really an issue if the modules in the directory in the
>> document tree are being imported directly by mod_python importer
>> by reference in Python*Handler, by mod_python.publisher or by
>> direct use by apache.import_module(). If the modules in said
>> directory aren't being included in this way, it is okay to list
>> a subdirectory somewhere in the document tree in PythonPath.
>>
>> The important thing is that you want to avoid having modules imported
>> through both mechanisms.
>>
>> One step to ensure that anything in a directory isn't used by
>> mod_python
>> in some way inadvertantly by mod_python.publisher, is to add into the
>> directory a .htaccess file containing:
>>
>> deny from all
>>
>> If using own handler, not so big a deal.
>>
>> I have managed to get Cheetah to use mod_python importer from
>> within its
>> generated code before. The trick is to use import_module() instead of
>> __import__ to import the Cheetah template top level code file.
>>
>> Ie., don't use:
>>
>> module = __import__(modulename, globals(), locals(), [modulename])
>>
>> use:
>>
>> module = apache.import_module('/actual/path.py')
>>
>> Then have the templates directory in:
>>
>> PythonOption mod_python.importer.path ['/actual/path/to/templates']
>>
>> Try playing with that. If after my nine hour flight to next airport
>> I find some free internet access, I'll have a look to see how you
>> went.
>>
>> Anyway, hope I didn't muddle that because of being in a hurry.
>>
>> :-) :-) :-) :-)
>>
>> Graham
>>
>>
>>> http://www.modpython.org/live/mod_python-3.3.0b/doc-html/app-
>>> changes-
>>> from-3.2.10.html :
>>>> The PythonPath directive MUST not be used to point at directories
>>>> within the document tree.
>>>
>>> So I changed the PythonPath line in httpd.conf into
>>> PythonOption mod_python.importer.path "['/Users/dirk/Sites/www/
>>> python']"
>>>
>>> But –as somewhat expected– this breaks the Cheetah
>>> module
>> importing
>>> code.
>>> I tried to change it according to the docs
>>> (these http://www.modpython.org/live/mod_python-3.3.0b/doc-html/
>>> pyapi-
>>> apmeth.html )
>>>
>>> So now the code in main.py looks like this:
>>> ====================
>>> # for loading a Cheetah template
>>> templatesFolderLocation = "/Users/me/Sites/www/python/templates"
>>> # not appending to sys.path anymore
>>> ...
>>> modulename = 'page'
>>> ...
>>> try:
>>> module = apache.import_module(modulename, path=
>>> [templatesFolderLocation])
>>> except ImportError:
>>> ... # importing the module fails here!
>>> templateClass = getattr(module, name)
>>>
>>>
>>> The reason for the failing import seems to be the inheritance system
>>> of the templates. Inside the chain of Cheetah modules that are
>>> inheriting eachother, there is a pure python module (framework.py),
>>> residing in /www/python (not in /www/python/templates/ !) which
>>> tries
>>> to import a module from /www/python/templates/ through this line:
>>> from baseTemplate import baseTemplate
>>> I believe this fails and is the origin of my new problem.
>>>
>>> I thought the module search path, which I supplied with the path=
>>> argument in import_module() was copied forward to all subsequent
>>> imports, but it seems this does not work for me.
>>>
>>> Now I would be happy to add the templates directory to the python
>>> path again, but as I understood this is not the proper new
>>> mod_python
>>> way.
>>> However I am reluctant to change the importing mechanism in
>>> framework.py and make framework dependant on mod_python's apache,
>>> since I also want to be able to test the cheetah part of my system
>>> outside of apache.
>>>
>>> I hope I am missing something obvious. What would be the most clean
>>> and proper way to solve this issue?
>>>
From grahamd at dscpl.com.au Sun Feb 11 00:56:10 2007
From: grahamd at dscpl.com.au (Graham Dumpleton)
Date: Sun Feb 11 00:56:27 2007
Subject: [mod_python] PythonPath and importer in 3.3
Message-ID: <1171173370.19473@dscpl.user.openhosting.com>
Dirk van Oosterbosch, IR labs wrote ..
> However, I am not sure I am 100% happy with adding the path to the
> templates directory to the directive in httpd.conf. I rather add the
> extra module-search-directories in the hander module (main.py in my
> case) itself, possibly determining which directory is extra needed,
> based on the request. Is there a function to add to the importer path
> from a module itself?
Back in an airport again for a half hour shuttle flight.
You can do what you want by changing 'mod_python.importer.path'
from within the handler itself before any call to import_module().
options = req.get_options()
path = eval(options.get('mod_python.importer.path', []))
path.extend('/some/path/templates')
options['mod_python.importer.path'] = str(path)
At my next stop I should have Internet access again if ADSL install
we requested has been done properly. :-)
Graham
From colin.rothwell at frambroadband.com Sun Feb 11 12:09:03 2007
From: colin.rothwell at frambroadband.com (Colin Rothwell)
Date: Sun Feb 11 12:09:30 2007
Subject: [mod_python] CGIhandler Application Error
Message-ID: <45CF4DAF.6060202@frambroadband.com>
Hi All,
I'm quite new to python and very new mod_python. I have written a simple
app in the form of a CGI script which I am trying to get running CGIHandler.
The webserver setup I am using is Apache 2.2.4, Python 2.5 and
mod_python 3.3.0b.
This is a copy of the error.log info I get when I run the app. If you
need a copy of the app I can e-mail it to you.
[Sun Feb 11 15:41:28 2007] [error] [client 127.0.0.1] mod_python
(pid=2680, interpreter='www.theboff.net', phase='PythonHandler',
handler='mod_python.cgihandler'): Application error
[Sun Feb 11 15:41:28 2007] [error] [client 127.0.0.1] ServerName:
'www.theboff.net'
[Sun Feb 11 15:41:28 2007] [error] [client 127.0.0.1] DocumentRoot:
'D:/Apache2.2/htdocs'
[Sun Feb 11 15:41:28 2007] [error] [client 127.0.0.1] URI:
'/accounts/accounts.py'
[Sun Feb 11 15:41:28 2007] [error] [client 127.0.0.1] Location: None
[Sun Feb 11 15:41:28 2007] [error] [client 127.0.0.1] Directory:
'D:/Apache2.2/htdocs/accounts/'
[Sun Feb 11 15:41:28 2007] [error] [client 127.0.0.1] Filename:
'D:/Apache2.2/htdocs/accounts/accounts.py'
[Sun Feb 11 15:41:28 2007] [error] [client 127.0.0.1] PathInfo: ''
[Sun Feb 11 15:41:28 2007] [error] [client 127.0.0.1] Traceback (most
recent call last):
[Sun Feb 11 15:41:28 2007] [error] [client 127.0.0.1] File
"D:\\Python25\\Lib\\site-packages\\mod_python\\importer.py", line 1537,
in HandlerDispatch\n default=default_handler, arg=req,
silent=hlist.silent)
[Sun Feb 11 15:41:28 2007] [error] [client 127.0.0.1] File
"D:\\Python25\\Lib\\site-packages\\mod_python\\importer.py", line 1229,
in _process_target\n result = _execute_target(config, req, object, arg)
[Sun Feb 11 15:41:28 2007] [error] [client 127.0.0.1] File
"D:\\Python25\\Lib\\site-packages\\mod_python\\importer.py", line 1128,
in _execute_target\n result = object(arg)
[Sun Feb 11 15:41:28 2007] [error] [client 127.0.0.1] File
"D:\\Python25\\Lib\\site-packages\\mod_python\\cgihandler.py", line 96,
in handler\n imp.load_module(module_name, fd, path, desc)
[Sun Feb 11 15:41:28 2007] [error] [client 127.0.0.1] File
"D:/Apache2.2/htdocs/accounts\\accounts.py", line 52
[Sun Feb 11 15:41:28 2007] [error] [client 127.0.0.1] SyntaxError:
Non-ASCII character '\\xa3' in file
D:/Apache2.2/htdocs/accounts\\accounts.py on line 52, but no encoding
declared; see http://www.python.org/peps/pep-0263.html for details
(accounts.py, line 52)
Being a python noivce I have absolutely no idea as to how to solve this
problem. The app seems to work fine because running it with it's output
redirected to a .html file produces the desired output.
Thanks in advance,
Colin
From clodoaldo.pinto.neto at gmail.com Sun Feb 11 12:29:01 2007
From: clodoaldo.pinto.neto at gmail.com (Clodoaldo)
Date: Sun Feb 11 12:29:07 2007
Subject: [mod_python] CGIhandler Application Error
In-Reply-To: <45CF4DAF.6060202@frambroadband.com>
References: <45CF4DAF.6060202@frambroadband.com>
Message-ID:
2007/2/11, Colin Rothwell :
> Hi All,
>
> I'm quite new to python and very new mod_python. I have written a simple
> app in the form of a CGI script which I am trying to get running CGIHandler.
> The webserver setup I am using is Apache 2.2.4, Python 2.5 and
> mod_python 3.3.0b.
> This is a copy of the error.log info I get when I run the app. If you
> need a copy of the app I can e-mail it to you.
>
>
> [Sun Feb 11 15:41:28 2007] [error] [client 127.0.0.1] SyntaxError:
> Non-ASCII character '\\xa3' in file
> D:/Apache2.2/htdocs/accounts\\accounts.py on line 52, but no encoding
> declared; see http://www.python.org/peps/pep-0263.html for details
> (accounts.py, line 52)
Try putting this line as the first line of the script:
# -*- coding: UTF-8 -*-
Replace UTF-8 with the appropriate encoding.
Note that Python names must be strictly ASCII and the above encoding
will only help in strings.
Regards,
--
Clodoaldo Pinto Neto
From colin.rothwell at frambroadband.com Sun Feb 11 13:16:47 2007
From: colin.rothwell at frambroadband.com (Colin Rothwell)
Date: Sun Feb 11 13:17:14 2007
Subject: [mod_python] HTML =?iso-8859-1?q?=A3_signs?=
Message-ID: <45CF5D8F.9070902@frambroadband.com>
Hi All,
I just worked out how to do it - I was being thick before.
You have to use the £ HTML entity for those who have had my
problem of ? signs causing a CGI script to not work due to encoding
problems.
Thanks for all your help,
Colin
From deron.meranda at gmail.com Sun Feb 11 13:53:19 2007
From: deron.meranda at gmail.com (Deron Meranda)
Date: Sun Feb 11 13:53:26 2007
Subject: =?UTF-8?Q?Re:_[mod=5Fpython]_HTML_=C2=A3_signs?=
In-Reply-To: <45CF5D8F.9070902@frambroadband.com>
References: <45CF5D8F.9070902@frambroadband.com>
Message-ID: <5c06fa770702111053y1e79eb40r251d15b7e5a10ba7@mail.gmail.com>
On 2/11/07, Colin Rothwell wrote:
> I just worked out how to do it - I was being thick before.
> You have to use the £ HTML entity for those who have had my
> problem of ? signs causing a CGI script to not work due to encoding
> problems.
Or better yet use "£" -- the entity reference "£" only exists
in older HTML, it is not present in the newer XHTML. The numeric
reference though works everyplace.
See http://en.wikipedia.org/wiki/Pound_sign
Deron Meranda
From david.cooper at compucat.com Tue Feb 13 21:53:42 2007
From: david.cooper at compucat.com (David Cooper)
Date: Tue Feb 13 21:54:56 2007
Subject: [mod_python] Handler return value is rendered in output
Message-ID:
Hi Guys,
Firstly thanks for reading - I'm a complete newb to mod_python, having
installed it only yesterday.
I have had some success with the provided examples, however I've got
some troubles with the return value of my handlers being rendered in the
output. The following code renders a 0 on the page, which is not what I
expected?
--- form.html ---
--- comment.py ---
from mod_python import apache
def comment(req, comment):
return apache.OK
Also, if I return apache.HTTP_NOT_FOUND then I just get a page with 404
rendered at the top.
Question: Why is my return value being interpreted as text to be
rendered, rather than the signal to the mod_python framework whether
everything's ok or not?
Thanks for any assistance!
Cheers, Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20070214/e139e1f2/attachment.html
From jpg at jgassociates.ca Tue Feb 13 22:24:49 2007
From: jpg at jgassociates.ca (Jim Gallacher)
Date: Tue Feb 13 22:21:38 2007
Subject: [mod_python] Handler return value is rendered in output
In-Reply-To:
References:
Message-ID: <45D28101.4090607@jgassociates.ca>
Hi David,
It looks like you are using the publisher handler. It works at a higher
level than a simple mod_python hanlder and looks after the apache return
value for you. Anything returned by the published method will be sent to
the client. For example
def comment(req):
return 'Hello world'
would return "Hello world" to the browser. This is why you are seeing
the extra 0 appended to your output.
Jim
David Cooper wrote:
> Hi Guys,
>
>
>
> Firstly thanks for reading - I'm a complete newb to mod_python, having
> installed it only yesterday.
>
>
>
> I have had some success with the provided examples, however I've got
> some troubles with the return value of my handlers being rendered in the
> output. The following code renders a 0 on the page, which is not what I
> expected?
>
>
>
> --- form.html ---
>
>
>
>
>
>
>
> --- comment.py ---
>
>
>
> from mod_python import apache
>
> def comment(req, comment):
>
> return apache.OK
>
>
>
> Also, if I return apache.HTTP_NOT_FOUND then I just get a page with 404
> rendered at the top.
>
>
>
> Question: Why is my return value being interpreted as text to be
> rendered, rather than the signal to the mod_python framework whether
> everything's ok or not?
>
>
>
> Thanks for any assistance!
>
>
>
> Cheers, Dave.
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mod_python mailing list
> Mod_python@modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python
From usenet at eugenemorozov.name Thu Feb 15 00:35:13 2007
From: usenet at eugenemorozov.name (Eugene Morozov)
Date: Thu Feb 15 00:40:16 2007
Subject: [mod_python] Apache and mod_python memory usage
Message-ID:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
We're using apache and mod_python for running Pylons-based CMS. We're a
little bit concerned with memory usage. With mod_python
apache2-mpm-worker consumes a lot of memory:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
23787 www-data 20 0 366m 48m 4104 S 0.0 12.5 0:09.23 apache2
48Mb is a bit too big even for apache. And why it needs 366Mb of virtual
memory?
If I disable mod_python these values are cut significantly (to 266Mb
virtual and 21Mb RSS, which is still much, it seems).
Not that it's a huge problem now, but I'm curious why so much memory is
consumed.
Eugene
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF0/ERk5VH2F5tiW4RAilgAJ0ZXaQ1j/nZkbBfolIvuBmiyMBVxACgxYZk
cdS74Zm1CF/Mv+PlQNXZGEM=
=js+p
-----END PGP SIGNATURE-----
From grisha at apache.org Thu Feb 15 16:54:13 2007
From: grisha at apache.org (Gregory (Grisha) Trubetskoy)
Date: Thu Feb 15 16:54:25 2007
Subject: [mod_python] ANNOUNCE: Mod_python 3.3.1
Message-ID: <20070215165246.H48122@grisha.dyndns.org>
The Apache Software Foundation and The Apache HTTP Server Project are
pleased to announce the 3.3.1 release of mod_python. Mod_python 3.3.1
is considered a stable release, suitable for production use.
Mod_python is an Apache HTTP Server module that embeds the Python
language interpreter within the server. With mod_python you can write
web-based applications in Python that will run many times faster than
traditional CGI and will have access to advanced features such as
ability to maintain objects between requests, access to httpd
internals, content filters and connection handlers.
The 3.3.1 release has many new features, feature enhancements, fixed
bugs and other improvements over the previous version. See Appendix A
of mod_python documentation for more details.
Mod_python 3.3.1 is released under the new Apache License version 2.0.
Mod_python 3.3.1 is available for download from:
http://httpd.apache.org/modules/python-download.cgi
More infromation about mod_python is available at:
http://httpd.apache.org/modules/
Many thanks to everyone who contributed to and helped test
this release, without your help it would not be possible!
Regards,
The Apache Mod_python team.
From grahamd at dscpl.com.au Thu Feb 15 21:35:02 2007
From: grahamd at dscpl.com.au (Graham Dumpleton)
Date: Thu Feb 15 21:35:08 2007
Subject: [mod_python] Apache and mod_python memory usage
Message-ID: <1171593302.27844@dscpl.user.openhosting.com>
Eugene Morozov wrote ..
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
> We're using apache and mod_python for running Pylons-based CMS. We're a
> little bit concerned with memory usage. With mod_python
> apache2-mpm-worker consumes a lot of memory:
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 23787 www-data 20 0 366m 48m 4104 S 0.0 12.5 0:09.23 apache2
>
> 48Mb is a bit too big even for apache. And why it needs 366Mb of virtual
> memory?
>
> If I disable mod_python these values are cut significantly (to 266Mb
> virtual and 21Mb RSS, which is still much, it seems).
>
> Not that it's a huge problem now, but I'm curious why so much memory is
> consumed.
What are the figures immediately after Apache has started and before any requests
have been handled by mod_python? When determining this, ensure that not
PythonImport directives are being applied to preload/execute any Python code.
This figure will be the initial starting size with only the main Python interpreter
instance created. Beyond that, the size will grow based on what your own Python
code is doing, how many additional Python interpreter instances are created or
possibly due to memory leaks.
As far as memory leaks in mod_python go, ensure that you are using the latest
version of mod_python, ie., 3.3. There are memory leaks in older versions which
depending on what your code is doing may be getting triggered.
As to Python interpreter instances, how many virtual hosts are you running on
the server under which mod_python requests are being handled? Also, are you
using any of PythonInterpPerDirectory or PythonInterpPerDirective or
PythonInterpreter directives? If you are using these and depending on how
you use them, you could be unnecessarily creating additional Python interpreter
instances which may be unnecessarily consuming additional memory.
Finally, does this figure keep going up and up over time which may indicate
memory leaks in mod_python or your own Python code?
Graham
PS. I finally have net access again. Been trying to get an ADSL connection going
where I am staying for most of the week. Finally came down to fact that ISP didn't
tell me or state anywhere on their sparse documentation what the correct
@something was that had to be placed after the ADSL login ID. Only after I asked
them a second time did they give me the correct value. Even though back on net,
access still restricted. Luckily list has been quiet anyway. :-)
From usenet at eugenemorozov.name Thu Feb 15 23:54:51 2007
From: usenet at eugenemorozov.name (Eugene Morozov)
Date: Thu Feb 15 23:54:54 2007
Subject: [mod_python] Re: Apache and mod_python memory usage
In-Reply-To: <1171593302.27844@dscpl.user.openhosting.com>
References: <1171593302.27844@dscpl.user.openhosting.com>
Message-ID:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
No, this figure is the initial starting size and it doesn't grow at all
with time. We currently have two virtual hosts running. I don't think
it's really a problem, just wanted to know if such initial memory
consumption is normal or not. Can anyone else post their figures?
Eugene
Graham Dumpleton ?????:
> Eugene Morozov wrote ..
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello,
>> We're using apache and mod_python for running Pylons-based CMS. We're a
>> little bit concerned with memory usage. With mod_python
>> apache2-mpm-worker consumes a lot of memory:
>>
>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>> 23787 www-data 20 0 366m 48m 4104 S 0.0 12.5 0:09.23 apache2
>>
>> 48Mb is a bit too big even for apache. And why it needs 366Mb of virtual
>> memory?
>>
>> If I disable mod_python these values are cut significantly (to 266Mb
>> virtual and 21Mb RSS, which is still much, it seems).
>>
>> Not that it's a huge problem now, but I'm curious why so much memory is
>> consumed.
>
> What are the figures immediately after Apache has started and before any requests
> have been handled by mod_python? When determining this, ensure that not
> PythonImport directives are being applied to preload/execute any Python code.
>
> This figure will be the initial starting size with only the main Python interpreter
> instance created. Beyond that, the size will grow based on what your own Python
> code is doing, how many additional Python interpreter instances are created or
> possibly due to memory leaks.
>
> As far as memory leaks in mod_python go, ensure that you are using the latest
> version of mod_python, ie., 3.3. There are memory leaks in older versions which
> depending on what your code is doing may be getting triggered.
>
> As to Python interpreter instances, how many virtual hosts are you running on
> the server under which mod_python requests are being handled? Also, are you
> using any of PythonInterpPerDirectory or PythonInterpPerDirective or
> PythonInterpreter directives? If you are using these and depending on how
> you use them, you could be unnecessarily creating additional Python interpreter
> instances which may be unnecessarily consuming additional memory.
>
> Finally, does this figure keep going up and up over time which may indicate
> memory leaks in mod_python or your own Python code?
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF1Tkak5VH2F5tiW4RAku7AKDRVyEqXh3JFyj3SCbJ40P+yirzEwCgs65e
jDg69zy25rbK6lb/Jt8G36c=
=23AR
-----END PGP SIGNATURE-----
From grisha at apache.org Thu Feb 15 16:54:13 2007
From: grisha at apache.org (Gregory (Grisha) Trubetskoy)
Date: Thu Feb 15 23:56:15 2007
Subject: [mod_python] ANNOUNCE: Mod_python 3.3.1
Message-ID: <20070215165246.H48122@grisha.dyndns.org>
The Apache Software Foundation and The Apache HTTP Server Project are
pleased to announce the 3.3.1 release of mod_python. Mod_python 3.3.1
is considered a stable release, suitable for production use.
Mod_python is an Apache HTTP Server module that embeds the Python
language interpreter within the server. With mod_python you can write
web-based applications in Python that will run many times faster than
traditional CGI and will have access to advanced features such as
ability to maintain objects between requests, access to httpd
internals, content filters and connection handlers.
The 3.3.1 release has many new features, feature enhancements, fixed
bugs and other improvements over the previous version. See Appendix A
of mod_python documentation for more details.
Mod_python 3.3.1 is released under the new Apache License version 2.0.
Mod_python 3.3.1 is available for download from:
http://httpd.apache.org/modules/python-download.cgi
More infromation about mod_python is available at:
http://httpd.apache.org/modules/
Many thanks to everyone who contributed to and helped test
this release, without your help it would not be possible!
Regards,
The Apache Mod_python team.
From grahamd at dscpl.com.au Fri Feb 16 05:27:02 2007
From: grahamd at dscpl.com.au (Graham Dumpleton)
Date: Fri Feb 16 05:27:12 2007
Subject: [mod_python] Re: Apache and mod_python memory usage
Message-ID: <1171621622.14187@dscpl.user.openhosting.com>
How big is your mod_python.so module for Apache? If Python was not built
so as to create a shared library for itself when mod_python.so is built it may
include the actual Python library itself. It is possible this shows as memory
used by process as opposed to shared memory if shared library was used.
On Mac OS X where equivalent of shared library used, Apache only consumes
a few MB of memory upon startup (from memory, can't confirm right now).
How it works on other platforms not exactly sure. If on UNIX like systems, can
run:
ldd mod_python.so
and it will indicate whether using Python as shared library.
Graham
Eugene Morozov wrote ..
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
> No, this figure is the initial starting size and it doesn't grow at all
> with time. We currently have two virtual hosts running. I don't think
> it's really a problem, just wanted to know if such initial memory
> consumption is normal or not. Can anyone else post their figures?
> Eugene
>
> Graham Dumpleton ??????????:
> > Eugene Morozov wrote ..
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Hello,
> >> We're using apache and mod_python for running Pylons-based CMS. We're
> a
> >> little bit concerned with memory usage. With mod_python
> >> apache2-mpm-worker consumes a lot of memory:
> >>
> >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> >> 23787 www-data 20 0 366m 48m 4104 S 0.0 12.5 0:09.23 apache2
> >>
> >> 48Mb is a bit too big even for apache. And why it needs 366Mb of virtual
> >> memory?
> >>
> >> If I disable mod_python these values are cut significantly (to 266Mb
> >> virtual and 21Mb RSS, which is still much, it seems).
> >>
> >> Not that it's a huge problem now, but I'm curious why so much memory
> is
> >> consumed.
> >
> > What are the figures immediately after Apache has started and before
> any requests
> > have been handled by mod_python? When determining this, ensure that not
> > PythonImport directives are being applied to preload/execute any Python
> code.
> >
> > This figure will be the initial starting size with only the main Python
> interpreter
> > instance created. Beyond that, the size will grow based on what your
> own Python
> > code is doing, how many additional Python interpreter instances are created
> or
> > possibly due to memory leaks.
> >
> > As far as memory leaks in mod_python go, ensure that you are using the
> latest
> > version of mod_python, ie., 3.3. There are memory leaks in older versions
> which
> > depending on what your code is doing may be getting triggered.
> >
> > As to Python interpreter instances, how many virtual hosts are you running
> on
> > the server under which mod_python requests are being handled? Also, are
> you
> > using any of PythonInterpPerDirectory or PythonInterpPerDirective or
> > PythonInterpreter directives? If you are using these and depending on
> how
> > you use them, you could be unnecessarily creating additional Python interpreter
> > instances which may be unnecessarily consuming additional memory.
> >
> > Finally, does this figure keep going up and up over time which may indicate
> > memory leaks in mod_python or your own Python code?
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFF1Tkak5VH2F5tiW4RAku7AKDRVyEqXh3JFyj3SCbJ40P+yirzEwCgs65e
> jDg69zy25rbK6lb/Jt8G36c=
> =23AR
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Mod_python mailing list
> Mod_python@modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python
From alexandremasbr at gmail.com Tue Feb 20 14:17:53 2007
From: alexandremasbr at gmail.com (Alexandre Miguel de Andrade Souza)
Date: Tue Feb 20 14:18:04 2007
Subject: [mod_python] how use sessions in modpython2.7?
Message-ID: <901098b40702201117r6ac8cc95h16f0d77c28080765@mail.gmail.com>
I see this feature at 3.3 (with apache2) but I need use apache1.3 and
modpython2.7.
someone have a alternative solution?
--
=========================
Alexandre Miguel de Andrade Souza
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20070220/a8f0b656/attachment.html
From grahamd at dscpl.com.au Tue Feb 20 22:16:58 2007
From: grahamd at dscpl.com.au (Graham Dumpleton)
Date: Tue Feb 20 22:17:07 2007
Subject: [mod_python] how use sessions in modpython2.7?
Message-ID: <1172027817.27407@dscpl.user.openhosting.com>
Alexandre Miguel de Andrade Souza wrote ..
> I see this feature at 3.3 (with apache2) but I need use apache1.3 and
> modpython2.7.
> someone have a alternative solution?
On the www.modpython.org web site type in "session mod_python 2.7" to
the search box, or similar search terms and you will find what other people
have done to solve this in the past. A couple of links from the search are:
http://www.modpython.org/pipermail/mod_python/2005-October/019349.html
http://www.modpython.org/pipermail/mod_python/2005-July/018668.html
>From memory there have been others suggested as well, you'll just need
to search the archives for them.
Graham
From ajdenstone at itaubank.com.br Wed Feb 21 13:53:21 2007
From: ajdenstone at itaubank.com.br (Denstone, Alexandre J)
Date: Wed Feb 21 13:54:15 2007
Subject: RES: [mod_python] ANNOUNCE: Mod_python 3.3.1
Message-ID:
Grisha,
I'm trying to use the new version of mod_python but I have the
following error:
[Wed Feb 21 16:47:35 2007] [error] python_init: Python version mismatch,
expected '2.4.3', found '2.4.4'.
Alexandre J Denstone
ajdenstone@itaubank.com.br
-----Mensagem original-----
De: mod_python-bounces@modpython.org
[mailto:mod_python-bounces@modpython.org] Em nome de Gregory (Grisha)
Trubetskoy
Enviada em: quinta-feira, 15 de fevereiro de 2007 19:54
Para: announce@httpd.apache.org; mod_python@modpython.org
Cc: python-dev@httpd.apache.org
Assunto: [mod_python] ANNOUNCE: Mod_python 3.3.1
The Apache Software Foundation and The Apache HTTP Server Project are
pleased to announce the 3.3.1 release of mod_python. Mod_python 3.3.1 is
considered a stable release, suitable for production use.
Mod_python is an Apache HTTP Server module that embeds the Python
language interpreter within the server. With mod_python you can write
web-based applications in Python that will run many times faster than
traditional CGI and will have access to advanced features such as
ability to maintain objects between requests, access to httpd internals,
content filters and connection handlers.
The 3.3.1 release has many new features, feature enhancements, fixed
bugs and other improvements over the previous version. See Appendix A of
mod_python documentation for more details.
Mod_python 3.3.1 is released under the new Apache License version 2.0.
Mod_python 3.3.1 is available for download from:
http://httpd.apache.org/modules/python-download.cgi
More infromation about mod_python is available at:
http://httpd.apache.org/modules/
Many thanks to everyone who contributed to and helped test this release,
without your help it would not be possible!
Regards,
The Apache Mod_python team.
_______________________________________________
Mod_python mailing list
Mod_python@modpython.org
http://mailman.modpython.org/mailman/listinfo/mod_python
Esta mensagem, incluindo seus anexos, pode conter informacao confidencial e/ou privilegiada. Se voce recebeu este e-mail por engano, nao utilize, copie ou divulgue as informacoes nele contidas. E, por favor, avise imediatamente o remetente, respondendo ao e-mail, e em seguida apague-o. Este e-mail possui conteudo informativo e nao transacional. Caso necessite de atendimento imediato, recomendamos utilizar um dos canais disponiveis: Internet Banking, Atendimento por Telefone ou agencia/representante de atendimento de sua conveniencia. Agradecemos sua colaboracao.
From grahamd at dscpl.com.au Thu Feb 22 05:40:51 2007
From: grahamd at dscpl.com.au (Graham Dumpleton)
Date: Thu Feb 22 05:42:04 2007
Subject: RES: [mod_python] ANNOUNCE: Mod_python 3.3.1
Message-ID: <1172140850.18632@dscpl.user.openhosting.com>
Because the only difference is the patch revision of Python this can generally
be ignored. What it probably means is that your 'python' and 'python-dev'
packages are out of sync. Ie., using 'python-2.4.4' and 'python-dev-2.4.3'.
The 'dev' package is used during compilation and it is finding 2.4.3 version
number at that point. This is compared at runtime with that which is embedded
into Python which comes from core Python package. Will generate these
warnings if they differ.
So, check your OS package versions and make sure they are for the same version
of Python.
Graham
Denstone, Alexandre J wrote ..
>
> Grisha,
>
> I'm trying to use the new version of mod_python but I have the
> following error:
>
> [Wed Feb 21 16:47:35 2007] [error] python_init: Python version mismatch,
> expected '2.4.3', found '2.4.4'.
>
>
> Alexandre J Denstone
> ajdenstone@itaubank.com.br
>
> -----Mensagem original-----
> De: mod_python-bounces@modpython.org
> [mailto:mod_python-bounces@modpython.org] Em nome de Gregory (Grisha)
> Trubetskoy
> Enviada em: quinta-feira, 15 de fevereiro de 2007 19:54
> Para: announce@httpd.apache.org; mod_python@modpython.org
> Cc: python-dev@httpd.apache.org
> Assunto: [mod_python] ANNOUNCE: Mod_python 3.3.1
>
>
> The Apache Software Foundation and The Apache HTTP Server Project are
> pleased to announce the 3.3.1 release of mod_python. Mod_python 3.3.1 is
> considered a stable release, suitable for production use.
>
> Mod_python is an Apache HTTP Server module that embeds the Python
> language interpreter within the server. With mod_python you can write
> web-based applications in Python that will run many times faster than
> traditional CGI and will have access to advanced features such as
> ability to maintain objects between requests, access to httpd internals,
> content filters and connection handlers.
>
> The 3.3.1 release has many new features, feature enhancements, fixed
> bugs and other improvements over the previous version. See Appendix A of
> mod_python documentation for more details.
>
> Mod_python 3.3.1 is released under the new Apache License version 2.0.
>
> Mod_python 3.3.1 is available for download from:
>
> http://httpd.apache.org/modules/python-download.cgi
>
> More infromation about mod_python is available at:
>
> http://httpd.apache.org/modules/
>
> Many thanks to everyone who contributed to and helped test this release,
> without your help it would not be possible!
>
> Regards,
>
> The Apache Mod_python team.
> _______________________________________________
> Mod_python mailing list
> Mod_python@modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python
>
> Esta mensagem, incluindo seus anexos, pode conter informacao confidencial
> e/ou privilegiada. Se voce recebeu este e-mail por engano, nao utilize,
> copie ou divulgue as informacoes nele contidas. E, por favor, avise imediatamente
> o remetente, respondendo ao e-mail, e em seguida apague-o. Este e-mail
> possui conteudo informativo e nao transacional. Caso necessite de atendimento
> imediato, recomendamos utilizar um dos canais disponiveis: Internet Banking,
> Atendimento por Telefone ou agencia/representante de atendimento de sua
> conveniencia. Agradecemos sua colaboracao.
>
>
> _______________________________________________
> Mod_python mailing list
> Mod_python@modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python
From john_nowlan at carleton.ca Thu Feb 22 15:01:18 2007
From: john_nowlan at carleton.ca (John_Nowlan)
Date: Thu Feb 22 15:01:51 2007
Subject: [mod_python] Showing sys.executable would be a useful addition to
mod_python.testhandler.py would it not?
Message-ID: <6A5D305B0DE17541907AC0448C828A71012FB1BF@CCSEXB10.CUNET.CARLETON.CA>
req.write('%s | %s |
\n'%(
'Python executable',
sys.executable
))
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20070222/8ff8d1bb/attachment.html
From rory at campbell-lange.net Thu Feb 22 17:40:56 2007
From: rory at campbell-lange.net (Rory Campbell-Lange)
Date: Thu Feb 22 17:41:01 2007
Subject: [mod_python] mod_python, django and class variables
Message-ID: <20070222224056.GH30395@campbell-lange.net>
Hi. I'm trying out the Django web framework, which I am running through
mod_python. I mention this because I am not clear precisely how Django
hooks into mod_python.
However it has become clear that we have a problem with class variables.
A simple version of our problem is depicted below. Essentially we need
to aggregate data between instances of a class, and have been using
class variables to do this. Under mod_python the class variables keep
incrementing, however, as common-sense (but alas, not foresight)
dictates.
I would be very grateful for advice on how to somehow make our class
variables local to any particular invocation of the script in which they
are accessed.
Regards
Rory
class Part (object):
totalgia = 0
def __init__(self, gia):
self.gia = gia # gross internal area
self.giaratio = 0
Part.totalgia += self.gia
def addavgbm(self):
self.giaratio = float(self.gia)/float(Part.totalgia)
def __repr__(self):
return "gia: %0.1f giaratio: %0.2f" % (self.gia, self.giaratio)
if __name__ == '__main__':
p1 = Part(20)
p2 = Part(30)
for p in p1, p2:
p.addavgbm()
print p
From dkramer at aptima.com Thu Feb 22 17:53:38 2007
From: dkramer at aptima.com (David Kramer)
Date: Thu Feb 22 17:53:57 2007
Subject: [mod_python] Differences between mod_python under Windows and Linux?
Message-ID: <45DE1EF2.7020402@aptima.com>
Hi. New to the list.
We're porting an old mod_python application from Windows to Red Hat
Enterprise Linux 4. That means Apache 2.0.5, Python 2.3.5, mod_python
3.1.3, MySQLdb 1.2.0, and MySQL 4.0. So far the issues haven't been
major, but...
It appears that under Windows, when we create objects on a page with a
form, when that page gets called again to handle the submit, that object
is still there, as if it were running as a persistent web service.
Under Linux, this is not happening, and it is as if the page is executed
anew each invocation (which makes more sense to me).
I'll admin I inherited this code, so I could be missing something in the
code, but can someone confirm that there is no difference between how
things work on those two platforms?
Thanks in advance. If I hear that there is no difference, I may throw
together a small example program to demonstrate. Hope that's OK with
this list.
Thanks in advance.
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
From grahamd at dscpl.com.au Thu Feb 22 21:11:58 2007
From: grahamd at dscpl.com.au (Graham Dumpleton)
Date: Thu Feb 22 21:12:12 2007
Subject: [mod_python] Differences between mod_python under Windows and
Linux?
Message-ID: <1172196718.21266@dscpl.user.openhosting.com>
Read:
http://www.dscpl.com.au/wiki/ModPython/Articles/TheProcessInterpreterModel
The difference which is causing the behaviour you are seeing is that on
non Windows platforms there can be multiple Apache child processes
and these processes don't share data.
Graham
David Kramer wrote ..
> Hi. New to the list.
>
> We're porting an old mod_python application from Windows to Red Hat
> Enterprise Linux 4. That means Apache 2.0.5, Python 2.3.5, mod_python
> 3.1.3, MySQLdb 1.2.0, and MySQL 4.0. So far the issues haven't been
> major, but...
>
> It appears that under Windows, when we create objects on a page with a
> form, when that page gets called again to handle the submit, that object
> is still there, as if it were running as a persistent web service.
> Under Linux, this is not happening, and it is as if the page is executed
> anew each invocation (which makes more sense to me).
>
> I'll admin I inherited this code, so I could be missing something in the
> code, but can someone confirm that there is no difference between how
> things work on those two platforms?
>
> Thanks in advance. If I hear that there is no difference, I may throw
> together a small example program to demonstrate. Hope that's OK with
> this list.
>
> Thanks in advance.
>
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged material.
> Any review, retransmission, dissemination or other use of, or taking of
> any action in reliance upon this information by persons or entities other
> than the intended recipient is prohibited. If you received this in error,
> please contact the sender and delete the material from any computer.
>
> _______________________________________________
> Mod_python mailing list
> Mod_python@modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python
From mailtolanger at googlemail.com Fri Feb 23 09:20:40 2007
From: mailtolanger at googlemail.com (Stefan Langer)
Date: Fri Feb 23 09:18:33 2007
Subject: [mod_python] Problem with mod_python and trac using xmlrpcplugin
Message-ID: <45DEF838.1000007@googlemail.com>
Hello,
I'm running into a strange problem using trac with mod_python on apache.
First of my enviroment:
Linux Suse 9.3,
Apache 2.0.53,
Trac 0.10.3, (XmpRpcPlugin 0.1)
Mod_python 3.3.1
Running trac through the webfrontend works fine and I have no issues
with it but whenever I use the xmlrpcplugin to update a ticket in trac
and then try to reread the updated ticket i see the following error in
the apache log:
python_handler: Can't get/create interpreter.
My python sys.path is:
/usr/share/trac
/usr/lib/python2.4
/usr/local/lib/svn-python
/usr/lib/python2.4/site-packages/setuptools-0.6c5-py2.4.egg
/usr/lib/python2.4/site-packages/TracWebAdmin-0.1.2dev_r4429-py2.4.egg
/usr/lib/python2.4/site-packages/TracXMLRPC-0.1-py2.4.egg
/usr/lib/python24.zip
/usr/lib/python2.4
/usr/lib/python2.4/plat-linux2
/usr/lib/python2.4/lib-tk
/usr/lib/python2.4/lib-dynload
/usr/lib/python2.4/site-packages
my path is:
/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin
both retreived through the mod_python.testhandler
I googled the above error but only found stuff related to windows and
that it has something to do with permissions but I'm unable to see how
this relates to my enviroment. I checked if python directory can be read
by the apache user and it can.
I also asked at the mylar newsgroup (mylar is the client calling the
xmlrpcplugin) and the author of xmlrpcplugin both telling me that it has
nothing to do with their code.
Can anybody tell me how I can solve this?
thanks for any help
Stefan
P.S.: I only have a rudimentary knowledge of python or mod_python.
From lisicky at opt.cd.cz Fri Feb 23 10:09:20 2007
From: lisicky at opt.cd.cz (=?UTF-8?Q?Lisick=C3=BD_Ji=C5=99=C3=AD?=)
Date: Fri Feb 23 10:09:40 2007
Subject: [mod_python] filename for return file_content
Message-ID: <1172243360.2501.26.camel@lisicky-jiri.opt.cd.cz>
Hello,
I am using mod_python publisher and I want send tar.gz file to
client. File is not acessible by apache. I am using this code:
def send_file(req):
req.content_type = "application/x-gzip"
file = open("/some/path/file.tar.gz").read()
return file
But problem is, that this file have name as python function, that send
it with extension gz. So send_file.gz. And I need also tar extension.
Is there better way, that copy this file to directory, where apache
see it?
BTW MSIE is also "very funny". If I get http://www/file.tgz MSIE save
it as file.gz - so I must use tar.gz extension. (in firefox no problem)
From l.montecchiani at teamsystem.com Fri Feb 23 10:52:49 2007
From: l.montecchiani at teamsystem.com (Luca Montecchiani)
Date: Fri Feb 23 10:54:03 2007
Subject: [mod_python] filename for return file_content
In-Reply-To: <1172243360.2501.26.camel@lisicky-jiri.opt.cd.cz>
References: <1172243360.2501.26.camel@lisicky-jiri.opt.cd.cz>
Message-ID: <45DF0DD1.3080107@teamsystem.com>
Use sendfile, there are examples in the mailing list
the only advice is to add those headers :
_stat = os.stat( file_path )
fsize = str(_stat.st_size)
req.headers_out["Content-Length"] = fsize
req.headers_out["Content-Disposition"] = "attachment; filename=%s" % \
os.path.basename(file_path)
req.sendfile(file_path)
bye,
luca
Lisick? Ji?? wrote:
> Hello,
>
> I am using mod_python publisher and I want send tar.gz file to
> client. File is not acessible by apache. I am using this code:
>
> def send_file(req):
> req.content_type = "application/x-gzip"
> file = open("/some/path/file.tar.gz").read()
> return file
>
> But problem is, that this file have name as python function, that send
> it with extension gz. So send_file.gz. And I need also tar extension.
>
> Is there better way, that copy this file to directory, where apache
> see it?
>
> BTW MSIE is also "very funny". If I get http://www/file.tgz MSIE save
> it as file.gz - so I must use tar.gz extension. (in firefox no problem)
>
>
> _______________________________________________
> Mod_python mailing list
> Mod_python@modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python
--
Luca Montecchiani
Software Di Base
TeamSystem S.r.l.
------------------------------------------------------------------------------------------
Informativa ai sensi del D. Lgs. 196-30/06/2003.
Il contenuto di questa e.mail e degli eventuali allegati, deve essere
nella disponibilit?
del solo destinatario. Se ricevete per errore questa e-mail siete
pregati di informarci
(rispedendola al mittente) e di provvedere alla sua rimozione.
Possono essere presenti informazioni riservate e non corrette
(parzialmente o totalmente).
Le e-mail in partenza e in arrivo possono essere oggetto di monitoraggio
da parte di Teamsystem spa. Del contenuto ? responsabile il mittente
della presente.
Chiunque venga in possesso non autorizzato di questa e-mail ? vincolato
dalla Legge a non leggerne il contenuto, a non copiarla, a non
diffonderla e a non usarla.
Informiamo che per l' esercizio dei diritti di cui all'art. 7 del
d.lgs.196/2003 ci si pu?
rivolgere al Titolare del trattamento Teamsystem S.r.l. via Gagarin 205
61100 PESARO
per posta o fax, indicando sulla busta o sul foglio la dicitura
"Inerente alla Privacy",
o inviando una e-mail all' indirizzo privacy@teamsystem.com .
------------------------------------------------------------------------------------------
From petersanchez at gmail.com Sat Feb 24 14:50:22 2007
From: petersanchez at gmail.com (Peter Sanchez)
Date: Sat Feb 24 14:50:30 2007
Subject: [mod_python] Multiple functions
Message-ID:
This may be a weird question. I have a site running off a single 1U
that is serving more than 10M page views per month. It is 100% in
mod_python using publisher. I have done what I can to increase
performance server wise and I do need to add a second server to help
with the load. I am wondering if I can speed it up a bit in the code
itself by splitting it into multiple files.
Currently I have 90% of the code in a single index.py file. All "web"
end functions reside there. I assume it would be faster to have a
browse.py instead of a browse() function in index.py. Is this
thinking correct? My logic is the engine will just need to read the
browse function instead of the entire index.py file, then use the
browse only function.
All advice is welcome and appreciated!
Peter
From roberto at connexer.com Sat Feb 24 14:55:12 2007
From: roberto at connexer.com (Roberto C. Sanchez)
Date: Sat Feb 24 14:55:17 2007
Subject: [mod_python] Multiple functions
In-Reply-To:
References:
Message-ID: <20070224195512.GE29700@santiago.connexer.com>
On Sat, Feb 24, 2007 at 11:50:22AM -0800, Peter Sanchez wrote:
>
> Currently I have 90% of the code in a single index.py file. All "web"
> end functions reside there. I assume it would be faster to have a
> browse.py instead of a browse() function in index.py. Is this
> thinking correct? My logic is the engine will just need to read the
> browse function instead of the entire index.py file, then use the
> browse only function.
>
I would think that since Apache is capable of caching, this may not help
as much as you think. What version of Apache is this using?
Regards,
-Roberto
--
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20070224/d9f5730c/attachment.bin
From petersanchez at gmail.com Sat Feb 24 15:09:42 2007
From: petersanchez at gmail.com (Peter Sanchez)
Date: Sat Feb 24 15:09:51 2007
Subject: [mod_python] Multiple functions
In-Reply-To: <20070224195512.GE29700@santiago.connexer.com>
References:
<20070224195512.GE29700@santiago.connexer.com>
Message-ID: <95B31FAE-3333-4E78-94D9-2D41404AEACA@gmail.com>
I am using apache-2.0.58, mod_python-3.2.8 and python-2.4.3.
Good point about the caching. I am still thinking of separating them
if only for organization advantages.
Peter
BTW, nice last name ;)
On Feb 24, 2007, at 11:55 AM, Roberto C. Sanchez wrote:
> On Sat, Feb 24, 2007 at 11:50:22AM -0800, Peter Sanchez wrote:
>>
>> Currently I have 90% of the code in a single index.py file. All "web"
>> end functions reside there. I assume it would be faster to have a
>> browse.py instead of a browse() function in index.py. Is this
>> thinking correct? My logic is the engine will just need to read the
>> browse function instead of the entire index.py file, then use the
>> browse only function.
>>
> I would think that since Apache is capable of caching, this may not
> help
> as much as you think. What version of Apache is this using?
>
> Regards,
>
> -Roberto
>
> --
> Roberto C. Sanchez
> http://people.connexer.com/~roberto
> http://www.connexer.com
> _______________________________________________
> Mod_python mailing list
> Mod_python@modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python
From roberto at connexer.com Sat Feb 24 15:14:30 2007
From: roberto at connexer.com (Roberto C. Sanchez)
Date: Sat Feb 24 15:14:34 2007
Subject: [mod_python] Multiple functions
In-Reply-To: <95B31FAE-3333-4E78-94D9-2D41404AEACA@gmail.com>
References:
<20070224195512.GE29700@santiago.connexer.com>
<95B31FAE-3333-4E78-94D9-2D41404AEACA@gmail.com>
Message-ID: <20070224201430.GA2783@santiago.connexer.com>
On Sat, Feb 24, 2007 at 12:09:42PM -0800, Peter Sanchez wrote:
> I am using apache-2.0.58, mod_python-3.2.8 and python-2.4.3.
>
> Good point about the caching. I am still thinking of separating them
> if only for organization advantages.
>
Yup. Apache2 does some pretty good caching. Out of curiousity, are you
seeing the server under heavy load all the time? If not, what has
precipitated your effort to increase efficiency.
> Peter
>
> BTW, nice last name ;)
>
Thanks. Same to you :)
Regards,
-Roberto
--
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20070224/594d4a83/attachment.bin
From petersanchez at gmail.com Sat Feb 24 15:28:21 2007
From: petersanchez at gmail.com (Peter Sanchez)
Date: Sat Feb 24 15:28:41 2007
Subject: [mod_python] Multiple functions
In-Reply-To: <20070224201430.GA2783@santiago.connexer.com>
References:
<20070224195512.GE29700@santiago.connexer.com>
<95B31FAE-3333-4E78-94D9-2D41404AEACA@gmail.com>
<20070224201430.GA2783@santiago.connexer.com>
Message-ID: <73D2C1DF-468B-42C4-989F-5E6887679808@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Feb 24, 2007, at 12:14 PM, Roberto C. Sanchez wrote:
> On Sat, Feb 24, 2007 at 12:09:42PM -0800, Peter Sanchez wrote:
>> I am using apache-2.0.58, mod_python-3.2.8 and python-2.4.3.
>>
>> Good point about the caching. I am still thinking of separating them
>> if only for organization advantages.
>>
> Yup. Apache2 does some pretty good caching. Out of curiousity,
> are you
> seeing the server under heavy load all the time? If not, what has
> precipitated your effort to increase efficiency.
Yes, the server is under a heavy load. I have tweaked apache a bit,
but maybe there is some documentation on mod_python specific tweaks
to increase performance. Also, PostgreSQL is also part of the issue.
I deployed pgpool, which has *really* helped. These are really the
only 2 major applications running on the server, which is FreeBSD 6.2-
STABLE.
Peter
>
>> Peter
>>
>> BTW, nice last name ;)
>>
> Thanks. Same to you :)
>
> Regards,
>
> -Roberto
>
> --
> Roberto C. Sanchez
> http://people.connexer.com/~roberto
> http://www.connexer.com
> _______________________________________________
> Mod_python mailing list
> Mod_python@modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFF4J/vSUSSjSUJmRkRAjkmAJsHPqMcdlotMOY9asT1coS2M6keDwCfbAq5
RApRqVrpJfR4oLUNjafKzNo=
=Ed84
-----END PGP SIGNATURE-----
From gwidion at mpc.com.br Sun Feb 25 01:05:12 2007
From: gwidion at mpc.com.br (Joao S. O. Bueno Calligaris)
Date: Sun Feb 25 01:05:15 2007
Subject: [mod_python] Multiple functions
In-Reply-To: <20070224195512.GE29700@santiago.connexer.com>
References:
<20070224195512.GE29700@santiago.connexer.com>
Message-ID: <200702250305.12634.gwidion@mpc.com.br>
On Saturday 24 February 2007 16:55, Roberto C. Sanchez wrote:
> On Sat, Feb 24, 2007 at 11:50:22AM -0800, Peter Sanchez wrote:
> > Currently I have 90% of the code in a single index.py file. All
> > "web" end functions reside there. I assume it would be faster to
> > have a browse.py instead of a browse() function in index.py. Is
> > this thinking correct? My logic is the engine will just need to
> > read the browse function instead of the entire index.py file,
> > then use the browse only function.
>
> I would think that since Apache is capable of caching, this may not
> help as much as you think. What version of Apache is this using?
>
Actually, after the first request for each apache proccess, all your
python code will be inside the python interpreter alrady. Each method
compiled, stored in RAM, ready to give you results whenever needed in
minimal time.
Splitting the app at this point should not help you much. :-/
regards,
js
-><-
> Regards,
>
> -Roberto
From jpg at jgassociates.ca Sun Feb 25 10:49:39 2007
From: jpg at jgassociates.ca (Jim Gallacher)
Date: Sun Feb 25 10:48:13 2007
Subject: [mod_python] Multiple functions
In-Reply-To:
References:
Message-ID: <45E1B013.7080903@jgassociates.ca>
Peter Sanchez wrote:
> This may be a weird question. I have a site running off a single 1U that
> is serving more than 10M page views per month. It is 100% in mod_python
> using publisher. I have done what I can to increase performance server
> wise and I do need to add a second server to help with the load. I am
> wondering if I can speed it up a bit in the code itself by splitting it
> into multiple files.
>
> Currently I have 90% of the code in a single index.py file. All "web"
> end functions reside there. I assume it would be faster to have a
> browse.py instead of a browse() function in index.py. Is this thinking
> correct? My logic is the engine will just need to read the browse
> function instead of the entire index.py file, then use the browse only
> function.
>
> All advice is welcome and appreciated!
Are you using sessions?
Jim
From smilelover at centrum.cz Sun Feb 25 11:40:29 2007
From: smilelover at centrum.cz (Daniel Kvasnicka jr.)
Date: Sun Feb 25 11:35:55 2007
Subject: [mod_python] Catching all tracebacks from mod_python?
Message-ID: <1172421629.7310.7.camel@localhost>
Hi people,
I would like to implement a custom error pages system, that would allow
people to set custom resource to be an error page. With 404 error it's
no problem, because I can tell whether my handler finds a file or not.
The problem is that I don't know how to catch every error traceback from
mod_python. I can surround the content of my handler function with try &
except, but what if an error occures when processing the code after
"except"?
--
http://danielkvasnicka.php5.cz -- web & corporate design, programov?n?
internetov?ch a intranetov?ch aplikac?
From petersanchez at gmail.com Sun Feb 25 12:25:19 2007
From: petersanchez at gmail.com (Peter Sanchez)
Date: Sun Feb 25 12:25:28 2007
Subject: [mod_python] Multiple functions
In-Reply-To: <45E1B013.7080903@jgassociates.ca>
References:
<45E1B013.7080903@jgassociates.ca>
Message-ID:
On Feb 25, 2007, at 7:49 AM, Jim Gallacher wrote:
> Peter Sanchez wrote:
>> This may be a weird question. I have a site running off a single
>> 1U that is serving more than 10M page views per month. It is 100%
>> in mod_python using publisher. I have done what I can to increase
>> performance server wise and I do need to add a second server to
>> help with the load. I am wondering if I can speed it up a bit in
>> the code itself by splitting it into multiple files.
>> Currently I have 90% of the code in a single index.py file. All
>> "web" end functions reside there. I assume it would be faster to
>> have a browse.py instead of a browse() function in index.py. Is
>> this thinking correct? My logic is the engine will just need to
>> read the browse function instead of the entire index.py file, then
>> use the browse only function.
>> All advice is welcome and appreciated!
>
> Are you using sessions?
I am using a Cookie which contains a key, and they session data is
stored on the back end.
Peter
>
> Jim
From rguha at indiana.edu Sun Feb 25 15:58:04 2007
From: rguha at indiana.edu (Rajarshi Guha)
Date: Sun Feb 25 15:58:10 2007
Subject: [mod_python] matplotlib and mod_python
Message-ID: <1172437084.7355.11.camel@localhost>
Hi, I have a mod_python based application in which I would like to
generate a chart using matplotlib.
Currently, when I try to call the function that generates the chart I
get a 'HOME not writable' error. I realize why this is happening and so
I modified my apache startup script to export a HOME directory of '/tmp'
When this is done, the chart is generated, but when I try to dump the
chart to a file using:
canvas.print_figure( ... )
the file is always created in /tmp (i.e., the value of HOME), rather
than in the file that I specify (which is in a current directory that is
writable by apache).
Has anybody successfully used matplotlib in a mod_python application, to
actually save a chart to a disk file?
(I realize that one way would be to send back the raw image bytes, but
the image is supposed to be a part of an HTML page, so I can't go down
that path)
Any pointers would be greatly appreciated.
Thanks,
-------------------------------------------------------------------
Rajarshi Guha
GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE
-------------------------------------------------------------------
The Heineken Uncertainty Principle:
You can never be sure how many beers you had last night.
From greg at vig.co.nz Sun Feb 25 16:18:12 2007
From: greg at vig.co.nz (Greg Fawcett)
Date: Sun Feb 25 16:18:14 2007
Subject: [mod_python] matplotlib and mod_python
In-Reply-To: <1172437084.7355.11.camel@localhost>
References: <1172437084.7355.11.camel@localhost>
Message-ID: <928306280702251318y22440beegcec8741c562e398f@mail.gmail.com>
It would be interesting to see if you could open the file in /tmp and copy
the contents to your web directory. Or could you create a symlink to the
/tmp file?
Cheers!
Greg.
On 26/02/07, Rajarshi Guha wrote:
>
> Hi, I have a mod_python based application in which I would like to
> generate a chart using matplotlib.
>
> Currently, when I try to call the function that generates the chart I
> get a 'HOME not writable' error. I realize why this is happening and so
> I modified my apache startup script to export a HOME directory of '/tmp'
>
> When this is done, the chart is generated, but when I try to dump the
> chart to a file using:
>
> canvas.print_figure( ... )
>
> the file is always created in /tmp (i.e., the value of HOME), rather
> than in the file that I specify (which is in a current directory that is
> writable by apache).
>
> Has anybody successfully used matplotlib in a mod_python application, to
> actually save a chart to a disk file?
>
> (I realize that one way would be to send back the raw image bytes, but
> the image is supposed to be a part of an HTML page, so I can't go down
> that path)
>
> Any pointers would be greatly appreciated.
>
> Thanks,
>
> -------------------------------------------------------------------
> Rajarshi Guha
> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE
> -------------------------------------------------------------------
> The Heineken Uncertainty Principle:
> You can never be sure how many beers you had last night.
>
>
> _______________________________________________
> Mod_python mailing list
> Mod_python@modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20070226/28680ce0/attachment.html
From rguha at indiana.edu Sun Feb 25 16:51:09 2007
From: rguha at indiana.edu (Rajarshi Guha)
Date: Sun Feb 25 16:51:16 2007
Subject: [mod_python] matplotlib and mod_python
In-Reply-To: <928306280702251318y22440beegcec8741c562e398f@mail.gmail.com>
References: <1172437084.7355.11.camel@localhost>
<928306280702251318y22440beegcec8741c562e398f@mail.gmail.com>
Message-ID: <1172440269.7355.17.camel@localhost>
On Mon, 2007-02-26 at 10:18 +1300, Greg Fawcett wrote:
> It would be interesting to see if you could open the file in /tmp and
> copy the contents to your web directory. Or could you create a symlink
> to the /tmp file?
Aah! I should have tried this first.
However doing it now still doesn't work, i.e., no file is copied to my
current directory.
So I tried a simpler solution:
def index(req):
f = open('tmp/junk.txt', 'w')
f.write('junk')
f.close()
return 'Done'
Here tmp has permissions:
drwxrwxr-x 2 apache apache 4.0K Feb 23 22:10 tmp
This works for some PHP scripts I have which have to write image files
to a local (to the current directory) tmp directory.
However when I call the above code from my browser, the file junk.txt is
written to /tmp (i.e. the value of HOME that I set at Apache startup).
Is there something special that needs to be done to get mod_python code
to write to a disk file?
I'm running mod_python 3.1, Apache 2.2, Fedora Core 5, python 2.4
Thanks,
-------------------------------------------------------------------
Rajarshi Guha
GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE
-------------------------------------------------------------------
All power corrupts, but we need electricity.
From mailtolanger at googlemail.com Mon Feb 26 03:35:35 2007
From: mailtolanger at googlemail.com (Stefan Langer)
Date: Mon Feb 26 03:33:16 2007
Subject: [mod_python] Problem with mod_python ???
Message-ID: <45E29BD7.5090700@googlemail.com>
Hello,
I'm running into a strange problem using trac with mod_python on apache.
First of my enviroment:
Linux Suse 9.3,
Apache 2.0.53,
Trac 0.10.3, (XmpRpcPlugin 0.1)
Mod_python 3.3.1
Running trac through the webfrontend works fine and I have no issues
with it but whenever I use the xmlrpcplugin to update a ticket in trac
and then try to reread the updated ticket i see the following error in
the apache log:
python_handler: Can't get/create interpreter.
My python sys.path is:
/usr/share/trac
/usr/lib/python2.4
/usr/local/lib/svn-python
/usr/lib/python2.4/site-packages/setuptools-0.6c5-py2.4.egg
/usr/lib/python2.4/site-packages/TracWebAdmin-0.1.2dev_r4429-py2.4.egg
/usr/lib/python2.4/site-packages/TracXMLRPC-0.1-py2.4.egg
/usr/lib/python24.zip
/usr/lib/python2.4
/usr/lib/python2.4/plat-linux2
/usr/lib/python2.4/lib-tk
/usr/lib/python2.4/lib-dynload
/usr/lib/python2.4/site-packages
my path is:
/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin
both retreived through the mod_python.testhandler
I googled the above error but only found stuff related to windows and
that it has something to do with permissions but I'm unable to see how
this relates to my enviroment. I checked if python directory can be read
by the apache user and it can.
I also asked at the mylar newsgroup (mylar is the client calling the
xmlrpcplugin) and the author of xmlrpcplugin both telling me that it has
nothing to do with their code.
Can anybody tell me how I can solve this?
Any help greatly appreciated!
Stefan
P.S.: I only have a rudimentary knowledge of python or mod_python.
From fzwaard at gmail.com Mon Feb 26 03:38:05 2007
From: fzwaard at gmail.com (Frank Zwaard)
Date: Mon Feb 26 03:38:10 2007
Subject: [mod_python] matplotlib and mod_python
In-Reply-To: <1172440269.7355.17.camel@localhost>
References: <1172437084.7355.11.camel@localhost>
<928306280702251318y22440beegcec8741c562e398f@mail.gmail.com>
<1172440269.7355.17.camel@localhost>
Message-ID:
I usually save the figure directly in /var/www/html/myapplicationdir
using the command
savefig(filename,dpi=self.ndpi)
where filename is something like:
/var/www/html/myapplicationdir/myfilename.png
Since apache is running my script and the html tree is own by apache I
don't have any problem with the permissions.
Let me know if you want a sample code of what I have.
Cheers
Fr
From cboos at neuf.fr Mon Feb 26 05:18:53 2007
From: cboos at neuf.fr (Christian Boos)
Date: Mon Feb 26 05:18:53 2007
Subject: [mod_python] Problem with mod_python ???
In-Reply-To: <45E29BD7.5090700@googlemail.com>
References: <45E29BD7.5090700@googlemail.com>
Message-ID: <45E2B40D.6070304@neuf.fr>
Stefan Langer wrote:
> Hello,
>
> I'm running into a strange problem using trac with mod_python on apache.
>
> First of my enviroment:
> Linux Suse 9.3,
> Apache 2.0.53,
> Trac 0.10.3, (XmpRpcPlugin 0.1)
> ...
Hi Stefan,
It's most likely a conflict between incompatible expat libraries,
see e.g. http://trac.edgewall.org/ticket/4454 and
http://www.dscpl.com.au/wiki/ModPython/Articles/ExpatCausingApacheCrash
-- Christian
From jpg at jgassociates.ca Mon Feb 26 08:09:33 2007
From: jpg at jgassociates.ca (Jim Gallacher)
Date: Mon Feb 26 08:09:35 2007
Subject: [mod_python] Multiple functions
In-Reply-To:
References: <45E1B013.7080903@jgassociates.ca>
Message-ID: <45E2DC0D.6010807@jgassociates.ca>
Peter Sanchez wrote:
>
> On Feb 25, 2007, at 7:49 AM, Jim Gallacher wrote:
>
>> Peter Sanchez wrote:
>>> This may be a weird question. I have a site running off a single 1U
>>> that is serving more than 10M page views per month. It is 100% in
>>> mod_python using publisher. I have done what I can to increase
>>> performance server wise and I do need to add a second server to help
>>> with the load. I am wondering if I can speed it up a bit in the code
>>> itself by splitting it into multiple files.
>>> Currently I have 90% of the code in a single index.py file. All "web"
>>> end functions reside there. I assume it would be faster to have a
>>> browse.py instead of a browse() function in index.py. Is this
>>> thinking correct? My logic is the engine will just need to read the
>>> browse function instead of the entire index.py file, then use the
>>> browse only function.
>>> All advice is welcome and appreciated!
>>
>> Are you using sessions?
>
> I am using a Cookie which contains a key, and they session data is
> stored on the back end.
I should have asked if you where using mod_python's built-in session
handling, as there may be some things that can be optimized there. In
your particular case I have nothing to offer.
Jim
From dkramer at aptima.com Tue Feb 27 13:10:02 2007
From: dkramer at aptima.com (David Kramer)
Date: Tue Feb 27 13:10:39 2007
Subject: [mod_python] Session confusion
Message-ID: <45E473FA.4030207@aptima.com>
Hi. I'm pretty new to mod_python. I'm porting a mod_python program
from Windows to Linux, and ran into the problem I posted a week or so
ago, where under Windows, all the variables automatically persisted (due
to Apache being one process under Windows), and the program was written
to expect that. I'm trying to store and recall the data using a
session, but I'm having some strange problems, and some questions.
The biggest problem is that on occasion, when I call
sess = Session.Session(req)
the program just halts and never returns from that line. No errors in
/var/log/htttpd/error_log, and the page times out. What can cause that?
I can often get the program working again by deleting any cookies
created by it, then restarting Apache, but that's not exactly
production-ready.
I wrote a small test program that tries to create an instance of a small
class and store that in the session data, and that seems to work (though
I've never worked in a web evironment where you could store objects in
cookies without somehow serializing them yourself). Is that really the
case? Is there some rule about what can be stored in sessions and what
cannot?
Is there a way for me to see the contents of session data on the server?
I tried following the code in the Session module, but I'm not sure
where or in what format the data is stored. I'm guessing "dbm" is a
Berkeley database that gets stored in a file somewhere, so I should be
able to query it somehow. I read somewhere that the stored data is
pickled, so I'll have to write a Python program to display it, which
shouldn't be a problem.
Lastly, I found the Session documentation "rather lacking" at
http://www.modpython.org/live/current/doc-html/pyapi-sess.html
Are there any mod_python tutorials or examples or other docs that could
help me? I would love to RTFM, but I think I need a better FM.
Thanks in advance.
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
From dkramer at aptima.com Tue Feb 27 13:27:10 2007
From: dkramer at aptima.com (David Kramer)
Date: Tue Feb 27 13:27:36 2007
Subject: [mod_python] Session confusion
In-Reply-To: <45E473FA.4030207@aptima.com>
References: <45E473FA.4030207@aptima.com>
Message-ID: <45E477FE.90500@aptima.com>
David Kramer wrote:
> Hi. I'm pretty new to mod_python. I'm porting a mod_python program
> from Windows to Linux, and ran into the problem I posted a week or so
> ago, where under Windows, all the variables automatically persisted (due
> to Apache being one process under Windows), and the program was written
> to expect that. I'm trying to store and recall the data using a
> session, but I'm having some strange problems, and some questions.
>
> The biggest problem is that on occasion, when I call
> sess = Session.Session(req)
> the program just halts and never returns from that line. No errors in
> /var/log/htttpd/error_log, and the page times out. What can cause that?
> I can often get the program working again by deleting any cookies
> created by it, then restarting Apache, but that's not exactly
> production-ready.
>
> I wrote a small test program that tries to create an instance of a small
> class and store that in the session data, and that seems to work (though
> I've never worked in a web evironment where you could store objects in
> cookies without somehow serializing them yourself). Is that really the
> case? Is there some rule about what can be stored in sessions and what
> cannot?
>
> Is there a way for me to see the contents of session data on the server?
> I tried following the code in the Session module, but I'm not sure
> where or in what format the data is stored. I'm guessing "dbm" is a
> Berkeley database that gets stored in a file somewhere, so I should be
> able to query it somehow. I read somewhere that the stored data is
> pickled, so I'll have to write a Python program to display it, which
> shouldn't be a problem.
>
> Lastly, I found the Session documentation "rather lacking" at
> http://www.modpython.org/live/current/doc-html/pyapi-sess.html
> Are there any mod_python tutorials or examples or other docs that could
> help me? I would love to RTFM, but I think I need a better FM.
>
>
> Thanks in advance.
I neglected to mention that, since this is an older app, we're using
Python 2.3 and mod_python 3.1.3 and MySQLdb 1.2.0, under Red Hat
Enterprise 4.0.
Thanks again.
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
From jpg at jgassociates.ca Tue Feb 27 14:26:07 2007
From: jpg at jgassociates.ca (Jim Gallacher)
Date: Tue Feb 27 14:17:22 2007
Subject: [mod_python] Session confusion
In-Reply-To: <45E473FA.4030207@aptima.com>
References: <45E473FA.4030207@aptima.com>
Message-ID: <45E485CF.3090405@jgassociates.ca>
David Kramer wrote:
> Hi. I'm pretty new to mod_python. I'm porting a mod_python program
> from Windows to Linux, and ran into the problem I posted a week or so
> ago, where under Windows, all the variables automatically persisted (due
> to Apache being one process under Windows), and the program was written
> to expect that. I'm trying to store and recall the data using a
> session, but I'm having some strange problems, and some questions.
>
> The biggest problem is that on occasion, when I call
> sess = Session.Session(req)
> the program just halts and never returns from that line. No errors in
> /var/log/htttpd/error_log, and the page times out. What can cause that?
To protect the integrity of your session data, the sessions are locked
for the duration of the request. Usually when you get a deadlock it is
the result of creating 2 (or more) session instances within the same
request. For example, the following bit of code would deadlock:
def handler(req):
sess = Session.Session(req)
stuff(req)
return apache.OK
def stuff(req):
sess = Session.Session(req)
req.write('stuff called')
In the above code, the first session instance locks the session. The 2nd
call to Session in stuff() blocks as the session is already locked,
resulting in your deadlock.
The usual recommendation is to make sure you only create one session
instance per request, and pass that object around as an attribute of the
request object. For example the above code would look like this:
def handler(req):
req.session = Session.Session(req)
stuff(req)
return apache.OK
def stuff(req):
sess = req.session
req.write('stuff called')
> I can often get the program working again by deleting any cookies
> created by it, then restarting Apache, but that's not exactly
> production-ready.
>
> I wrote a small test program that tries to create an instance of a small
> class and store that in the session data, and that seems to work (though
> I've never worked in a web evironment where you could store objects in
> cookies without somehow serializing them yourself).
You are not storing the data in a cookie. Only the session id is set in
the cookie. The session data is stored on the server. Various backend
stores are available, depending on your mod_python version and your OS.
Regardless of the store used, the data is a python cPickle.
> Is that really the
> case? Is there some rule about what can be stored in sessions and what
> cannot?
For various reasons it's best to restrict your session data to simple
types such as lists, tuples, dictionaries, strings, integers, etc.
> Is there a way for me to see the contents of session data on the server?
> I tried following the code in the Session module, but I'm not sure
> where or in what format the data is stored. I'm guessing "dbm" is a
> Berkeley database that gets stored in a file somewhere, so I should be
> able to query it somehow.
Yes it is a dbm file, with the session id as the key. For mod_python 3.1
the default location, as I recall, is /tmp/mp_sess.dbm
> I read somewhere that the stored data is
> pickled,
True.
> so I'll have to write a Python program to display it, which
> shouldn't be a problem.
Also true.
db = dbm.open('/tmp/mp_sess.dbm', 'r')
sess = db[session_id]
> Lastly, I found the Session documentation "rather lacking" at
> http://www.modpython.org/live/current/doc-html/pyapi-sess.html
> Are there any mod_python tutorials or examples or other docs that could
> help me? I would love to RTFM, but I think I need a better FM.
Some people have been chipping away at some additional pages that you
may find useful:
http://wiki.apache.org/mod_python/CategoryExamples
Jim
From jpg at jgassociates.ca Tue Feb 27 14:29:20 2007
From: jpg at jgassociates.ca (Jim Gallacher)
Date: Tue Feb 27 14:20:33 2007
Subject: [mod_python] Session confusion
In-Reply-To: <45E477FE.90500@aptima.com>
References: <45E473FA.4030207@aptima.com> <45E477FE.90500@aptima.com>
Message-ID: <45E48690.3030806@jgassociates.ca>
David Kramer wrote:
> David Kramer wrote:
>> Hi. I'm pretty new to mod_python. I'm porting a mod_python program
>> from Windows to Linux, and ran into the problem I posted a week or so
>> ago, where under Windows, all the variables automatically persisted
>> (due to Apache being one process under Windows), and the program was
>> written to expect that. I'm trying to store and recall the data using
>> a session, but I'm having some strange problems, and some questions.
>>
>> The biggest problem is that on occasion, when I call
>> sess = Session.Session(req)
>> the program just halts and never returns from that line. No errors in
>> /var/log/htttpd/error_log, and the page times out. What can cause
>> that? I can often get the program working again by deleting any
>> cookies created by it, then restarting Apache, but that's not exactly
>> production-ready.
>>
>> I wrote a small test program that tries to create an instance of a
>> small class and store that in the session data, and that seems to work
>> (though I've never worked in a web evironment where you could store
>> objects in cookies without somehow serializing them yourself). Is
>> that really the case? Is there some rule about what can be stored in
>> sessions and what cannot?
>>
>> Is there a way for me to see the contents of session data on the
>> server? I tried following the code in the Session module, but I'm not
>> sure where or in what format the data is stored. I'm guessing "dbm"
>> is a Berkeley database that gets stored in a file somewhere, so I
>> should be able to query it somehow. I read somewhere that the stored
>> data is pickled, so I'll have to write a Python program to display it,
>> which shouldn't be a problem.
>>
>> Lastly, I found the Session documentation "rather lacking" at
>> http://www.modpython.org/live/current/doc-html/pyapi-sess.html
>> Are there any mod_python tutorials or examples or other docs that
>> could help me? I would love to RTFM, but I think I need a better FM.
>>
>>
>> Thanks in advance.
>
> I neglected to mention that, since this is an older app, we're using
> Python 2.3 and mod_python 3.1.3 and MySQLdb 1.2.0, under Red Hat
> Enterprise 4.0.
I know this may not be possible, but you should consider upgrading to
3.3.1. There have been a huge number of fixes and improvements since
3.1.3, including the plugging of a bunch of memory leaks. Those fixes
alone make the upgrade worthwhile in a production environment.
Jim
From grahamd at dscpl.com.au Tue Feb 27 16:44:41 2007
From: grahamd at dscpl.com.au (Graham Dumpleton)
Date: Tue Feb 27 16:46:27 2007
Subject: [mod_python] Session confusion
In-Reply-To: <45E485CF.3090405@jgassociates.ca>
References: <45E473FA.4030207@aptima.com> <45E485CF.3090405@jgassociates.ca>
Message-ID: <4DFB731A-F7E5-4BCA-BD49-969EF00ECE75@dscpl.com.au>
On 28/02/2007, at 6:26 AM, Jim Gallacher wrote:
> David Kramer wrote:
>> Is that really the case? Is there some rule about what can be
>> stored in sessions and what cannot?
>
> For various reasons it's best to restrict your session data to
> simple types such as lists, tuples, dictionaries, strings,
> integers, etc.
Read:
http://www.dscpl.com.au/wiki/ModPython/Articles/
IssuesWithSessionObjects
for some understanding of why one should restrict oneself to basic
types.
Graham
From jose.deleon at sun.com Tue Feb 27 19:17:00 2007
From: jose.deleon at sun.com (Jose De Leon)
Date: Tue Feb 27 19:13:08 2007
Subject: [mod_python] Mod_Python Make fails on Solaris 9
Message-ID: <45E4C9FC.50306@sun.com>
An HTML attachment was scrubbed...
URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20070227/36e8ded8/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6g_top.gif
Type: image/gif
Size: 3163 bytes
Desc: not available
Url : http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20070227/36e8ded8/6g_top-0001.gif
From roberto at connexer.com Tue Feb 27 19:31:54 2007
From: roberto at connexer.com (Roberto C. Sanchez)
Date: Tue Feb 27 19:31:59 2007
Subject: [mod_python] Mod_Python Make fails on Solaris 9
In-Reply-To: <45E4C9FC.50306@sun.com>
References: <45E4C9FC.50306@sun.com>
Message-ID: <20070228003154.GG26375@santiago.connexer.com>
On Tue, Feb 27, 2007 at 04:17:00PM -0800, Jose De Leon wrote:
>
>
Acchh! The goggles, they do nothing!
Jose, please configure Thunderbird to send plain text email.
Regards,
-Roberto
--
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20070227/fb4ad84d/attachment.bin
From grahamd at dscpl.com.au Tue Feb 27 20:19:46 2007
From: grahamd at dscpl.com.au (Graham Dumpleton)
Date: Tue Feb 27 20:21:33 2007
Subject: [mod_python] Mod_Python Make fails on Solaris 9
In-Reply-To: <45E4C9FC.50306@sun.com>
References: <45E4C9FC.50306@sun.com>
Message-ID:
On 28/02/2007, at 11:17 AM, Jose De Leon wrote:
> I am about to rip my hair off! ... l been trying to figure out what
> is causing this compile problem any pointers or help in the right
> direction would be much appreciated. l have Apache 2.2.4 and are
> compiling Mod_Python with apxs
>
> strcat 0xff0 /usr/local/lib/
> python2.5/config/libpython2.5.a(import.o)
> strcat 0xffc /usr/local/lib/
> python2.5/config/libpython2.5.a(import.o)
> strcat 0x8f4 /usr/local/lib/
> python2.5/config/libpython2.5.a(getpath.o)
> strcat 0x900 /usr/local/lib/
> python2.5/config/libpython2.5.a(getpath.o)
> strcat 0x914 /usr/local/lib/
> python2.5/config/libpython2.5.a(getpath.o)
> strcat 0x93c /usr/local/lib/
> python2.5/config/libpython2.5.a(getpath.o)
> strcat 0x948 /usr/local/lib/
> python2.5/config/libpython2.5.a(getpath.o)
> strcat 0x990 /usr/local/lib/
> python2.5/config/libpython2.5.a(getpath.o)
> strcat 0x99c /usr/local/lib/
> python2.5/config/libpython2.5.a(getpath.o)
> strcat 0x9ac /usr/local/lib/
> python2.5/config/libpython2.5.a(getpath.o)
> strcat 0x12d0 /usr/local/lib/
> python2.5/config/libpython2.5.a(getpath.o)
> strcat 0x1538 /usr/local/lib/
> python2.5/config/libpython2.5.a(getpath.o)
> strcat 0x1858 /usr/local/lib/
> python2.5/config/libpython2.5.a(getpath.o)
> strcat 0x66c /usr/local/lib/
> python2.5/config/libpython2.5.a(complexobject.o)
> strcat 0x790 /usr/local/lib/
> python2.5/config/libpython2.5.a(complexobject.o)
> strcat 0x8a8 /usr/local/lib/
> python2.5/config/libpython2.5.a(complexobject.o)
> unlink 0x5910 /usr/local/lib/
> python2.5/config/libpython2.5.a(import.o)
> unlink 0x59b0 /usr/local/lib/
> python2.5/config/libpython2.5.a(import.o)
> unlink 0x15a8 /usr/local/lib/
> python2.5/config/libpython2.5.a(posixmodule.o)
> unlink 0x15ac /usr/local/lib/
> python2.5/config/libpython2.5.a(posixmodule.o)
> fseek 0x59e8 /usr/local/lib/
> python2.5/config/libpython2.5.a(import.o)
> fseek 0x48 /usr/local/lib/
> python2.5/config/libpython2.5.a(zipimport.o)
> fseek 0x148 /usr/local/lib/
> python2.5/config/libpython2.5.a(zipimport.o)
> fseek 0x170 /usr/local/lib/
> python2.5/config/libpython2.5.a(zipimport.o)
> fseek 0x1ec /usr/local/lib/
> python2.5/config/libpython2.5.a(zipimport.o)
> fseek 0x478 /usr/local/lib/
> python2.5/config/libpython2.5.a(zipimport.o)
> fseek 0x4a4 /usr/local/lib/
> python2.5/config/libpython2.5.a(zipimport.o)
> fseek 0x50c /usr/local/lib/
> python2.5/config/libpython2.5.a(zipimport.o)
>
> ld: fatal: relocations remain against allocatable but non-writable
> sections
> collect2: ld returned 1 exit status
> apxs:Error: Command failed with rc=65536
> .
> *** Error code 1
> make: Fatal error: Command failed for target `mod_python.so'
> Current working directory /tmp/mod_python-3.3.1/src
> *** Error code 1
> make: Fatal error: Command failed for target `do_dso'
On Solaris, if libtool can only find a static version of library, it
needs to be coaxed into
using it by ensuring the option:
-mimpure-text
is supplied to the linker.
I'm away from work so can't tell you where within makefiles or
otherwise you'll need to
add this manually.
For some details see:
http://gcc.gnu.org/ml/gcc-patches/2002-11/msg01815.html
Note the section about copy on write and stuff no longer acting like
shared objects.
This can mean that each Apache child process can end up being quite a
lot bigger
than it needs to as mod_python.so acts like a static object and not a
shared object.
Since the Python library is static it ends up being a part of the
mod_python.so as well
which just makes non shared memory used even more.
You should consider look at rebuilding Python and configure it to
generate a shared
library instead of a static if memory consumption is an issue.
Graham
From murthy.jayanthi at gmail.com Wed Feb 28 08:46:22 2007
From: murthy.jayanthi at gmail.com (Suryanarayana Murthy)
Date: Wed Feb 28 08:46:35 2007
Subject: [mod_python] mod_python make fails on solaris 10.
Message-ID:
Hi,
I have Apache 2.0.58 installed on my solaris server.
I downloaded mod_python 3.3.1 and executed configure with the following
options
./configure ?with-apxs=/usr/apache2/bin/apxs
?with-python=/usr/sfw/bin/python2.3 ?with-flex
configure scripts executes succesfully.
Later... when i run make I get the following error messages
bash-3.00# make
Compiling for DSO.
/usr/apache2/bin/apxs -I/export/home/binaries/mod_python-3.3.1/src/include
-I/usr/apache2/include -I/usr/sfw/include/python2.3 -c mod_python.c
_apachemodule.c requestobject.c tableobject.c util.c serverobject.c
connobject.c filterobject.c hlist.c hlistobject.c
finfoobject.c-L/usr/sfw/lib/python2.3/config -z ignore -lm -
lpython2.3 -lresolv -lsocket -lnsl -lrt -ldl -lm _eprintf.o
_floatdidf.o _muldi3.o
/var/apache2/build/libtool --silent --mode=compile /opt/SUNWspro/bin/cc
-prefer-pic -xO3 -xarch=v8 -xspace -W0,-Lt -W2,-Rcond_elim -Xa -xildoff
-DSSL_EXPERIMENTAL -DSSL_ENGINE -DSOLARIS2=10 -D_POSIX_PTHREAD_SEMANTICS
-D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/apache2/include -I/usr/apache2/include -I/usr/apache2/include
-I/export/home/binaries/mod_python-3.3.1/src/include -I/usr/apache2/include
-I/usr/sfw/include/python2.3 -c -o mod_python.lo mod_python.c && touch
mod_python.slo
/var/apache2/build/libtool: line 1279: /opt/SUNWspro/bin/cc: No such file or
directory
apxs:Error: Command failed with rc=65536
.
*** Error code 1
make: Fatal error: Command failed for target `mod_python.so'
Current working directory /export/home/binaries/mod_python-3.3.1/src
*** Error code 1
The following command caused the error:
cd src && make
make: Fatal error: Command failed for target `do_dso'
gcc is installed in /usr/sfw/bin and I have passed that information in the
CC environment flags
I Request help in getting this issues resolved.
--
Thanks 'n Regards,
Surya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20070228/449c3be6/attachment.html
From jose.deleon at sun.com Wed Feb 28 13:16:25 2007
From: jose.deleon at sun.com (Jose De Leon)
Date: Wed Feb 28 13:12:44 2007
Subject: [mod_python] Mod_Python Make fails on Solaris 9
In-Reply-To:
References: <45E4C9FC.50306@sun.com>
Message-ID: <45E5C6F9.9070207@sun.com>
Thank you Graham! You pointed me in the right direction :) ... l
recompiled Python 2.5 with Shared Libraries instead of Static, when l
recompiled Mod_Python it worked like a charm, thanks again :)
./configure --with-shared
Graham Dumpleton wrote:
>
> On 28/02/2007, at 11:17 AM, Jose De Leon wrote:
>
>> I am about to rip my hair off! ... l been trying to figure out what
>> is causing this compile problem any pointers or help in the right
>> direction would be much appreciated. l have Apache 2.2.4 and are
>> compiling Mod_Python with apxs
>>
>> strcat 0xff0
>> /usr/local/lib/python2.5/config/libpython2.5.a(import.o)
>> strcat 0xffc
>> /usr/local/lib/python2.5/config/libpython2.5.a(import.o)
>> strcat 0x8f4
>> /usr/local/lib/python2.5/config/libpython2.5.a(getpath.o)
>> strcat 0x900
>> /usr/local/lib/python2.5/config/libpython2.5.a(getpath.o)
>> strcat 0x914
>> /usr/local/lib/python2.5/config/libpython2.5.a(getpath.o)
>> strcat 0x93c
>> /usr/local/lib/python2.5/config/libpython2.5.a(getpath.o)
>> strcat 0x948
>> /usr/local/lib/python2.5/config/libpython2.5.a(getpath.o)
>> strcat 0x990
>> /usr/local/lib/python2.5/config/libpython2.5.a(getpath.o)
>> strcat 0x99c
>> /usr/local/lib/python2.5/config/libpython2.5.a(getpath.o)
>> strcat 0x9ac
>> /usr/local/lib/python2.5/config/libpython2.5.a(getpath.o)
>> strcat 0x12d0
>> /usr/local/lib/python2.5/config/libpython2.5.a(getpath.o)
>> strcat 0x1538
>> /usr/local/lib/python2.5/config/libpython2.5.a(getpath.o)
>> strcat 0x1858
>> /usr/local/lib/python2.5/config/libpython2.5.a(getpath.o)
>> strcat 0x66c
>> /usr/local/lib/python2.5/config/libpython2.5.a(complexobject.o)
>> strcat 0x790
>> /usr/local/lib/python2.5/config/libpython2.5.a(complexobject.o)
>> strcat 0x8a8
>> /usr/local/lib/python2.5/config/libpython2.5.a(complexobject.o)
>> unlink 0x5910
>> /usr/local/lib/python2.5/config/libpython2.5.a(import.o)
>> unlink 0x59b0
>> /usr/local/lib/python2.5/config/libpython2.5.a(import.o)
>> unlink 0x15a8
>> /usr/local/lib/python2.5/config/libpython2.5.a(posixmodule.o)
>> unlink 0x15ac
>> /usr/local/lib/python2.5/config/libpython2.5.a(posixmodule.o)
>> fseek 0x59e8
>> /usr/local/lib/python2.5/config/libpython2.5.a(import.o)
>> fseek 0x48
>> /usr/local/lib/python2.5/config/libpython2.5.a(zipimport.o)
>> fseek 0x148
>> /usr/local/lib/python2.5/config/libpython2.5.a(zipimport.o)
>> fseek 0x170
>> /usr/local/lib/python2.5/config/libpython2.5.a(zipimport.o)
>> fseek 0x1ec
>> /usr/local/lib/python2.5/config/libpython2.5.a(zipimport.o)
>> fseek 0x478
>> /usr/local/lib/python2.5/config/libpython2.5.a(zipimport.o)
>> fseek 0x4a4
>> /usr/local/lib/python2.5/config/libpython2.5.a(zipimport.o)
>> fseek 0x50c
>> /usr/local/lib/python2.5/config/libpython2.5.a(zipimport.o)
>>
>> ld: fatal: relocations remain against allocatable but non-writable
>> sections
>> collect2: ld returned 1 exit status
>> apxs:Error: Command failed with rc=65536
>> .
>> *** Error code 1
>> make: Fatal error: Command failed for target `mod_python.so'
>> Current working directory /tmp/mod_python-3.3.1/src
>> *** Error code 1
>> make: Fatal error: Command failed for target `do_dso'
>
> On Solaris, if libtool can only find a static version of library, it
> needs to be coaxed into
> using it by ensuring the option:
>
> -mimpure-text
>
> is supplied to the linker.
>
> I'm away from work so can't tell you where within makefiles or
> otherwise you'll need to
> add this manually.
>
> For some details see:
>
> http://gcc.gnu.org/ml/gcc-patches/2002-11/msg01815.html
>
> Note the section about copy on write and stuff no longer acting like
> shared objects.
> This can mean that each Apache child process can end up being quite a
> lot bigger
> than it needs to as mod_python.so acts like a static object and not a
> shared object.
> Since the Python library is static it ends up being a part of the
> mod_python.so as well
> which just makes non shared memory used even more.
>
> You should consider look at rebuilding Python and configure it to
> generate a shared
> library instead of a static if memory consumption is an issue.
>
> Graham
>
>
--
From grahamd at dscpl.com.au Wed Feb 28 16:03:47 2007
From: grahamd at dscpl.com.au (Graham Dumpleton)
Date: Wed Feb 28 16:03:53 2007
Subject: [mod_python] mod_python make fails on solaris 10.
Message-ID: <1172696627.9841@dscpl.user.openhosting.com>
Suryanarayana Murthy wrote ..
> Hi,
>
> I have Apache 2.0.58 installed on my solaris server.
>
> I downloaded mod_python 3.3.1 and executed configure with the following
> options
>
> ./configure ?with-apxs=/usr/apache2/bin/apxs
> ?with-python=/usr/sfw/bin/python2.3 ?with-flex
>
> configure scripts executes succesfully.
>
> Later... when i run make I get the following error messages
>
> bash-3.00# make
>
>
>
> Compiling for DSO.
>
>
>
> /usr/apache2/bin/apxs -I/export/home/binaries/mod_python-3.3.1/src/include
> -I/usr/apache2/include -I/usr/sfw/include/python2.3 -c mod_python.c
> _apachemodule.c requestobject.c tableobject.c util.c serverobject.c
> connobject.c filterobject.c hlist.c hlistobject.c
> finfoobject.c-L/usr/sfw/lib/python2.3/config -z ignore -lm -
> lpython2.3 -lresolv -lsocket -lnsl -lrt -ldl -lm _eprintf.o
> _floatdidf.o _muldi3.o
>
> /var/apache2/build/libtool --silent --mode=compile /opt/SUNWspro/bin/cc
> -prefer-pic -xO3 -xarch=v8 -xspace -W0,-Lt -W2,-Rcond_elim -Xa -xildoff
> -DSSL_EXPERIMENTAL -DSSL_ENGINE -DSOLARIS2=10 -D_POSIX_PTHREAD_SEMANTICS
> -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> -I/usr/apache2/include -I/usr/apache2/include -I/usr/apache2/include
> -I/export/home/binaries/mod_python-3.3.1/src/include -I/usr/apache2/include
> -I/usr/sfw/include/python2.3 -c -o mod_python.lo mod_python.c && touch
> mod_python.slo
>
> /var/apache2/build/libtool: line 1279: /opt/SUNWspro/bin/cc: No such file
> or
> directory
>
> apxs:Error: Command failed with rc=65536
>
> .
>
> *** Error code 1
>
> make: Fatal error: Command failed for target `mod_python.so'
>
> Current working directory /export/home/binaries/mod_python-3.3.1/src
>
> *** Error code 1
>
> The following command caused the error:
>
> cd src && make
>
> make: Fatal error: Command failed for target `do_dso'
>
> gcc is installed in /usr/sfw/bin and I have passed that information in
> the
> CC environment flags
>
> I Request help in getting this issues resolved.
Your Apache installation was compiled with Sun C compiler and not GCC. The
apxs configuration in Apache remembers this and thus all modules you try
and compile for Apache must thereafter use Sun C compiler as well. Try
adding the following at the beginning of your PATH.
/opt/SUNWspro/bin
This is where the Sun C compiler should be located if you have it installed. If
you don't have access to Sun C compiler, the simple choice is to rebuild and
reinstall Apache using GCC and then try again.
Graham