[jira] Resolved: (MODPYTHON-73) Using objects to create an explicit hierarchy.
[ http://issues.apache.org/jira/browse/MODPYTHON-73?page=all ] Nicolas Lehuen resolved MODPYTHON-73: - Fix Version: 3.2.0 Resolution: Fixed Checked in Graham's patch and wrote a unit test for it. Everything is OK. Using objects to create an explicit hierarchy. -- Key: MODPYTHON-73 URL: http://issues.apache.org/jira/browse/MODPYTHON-73 Project: mod_python Type: Improvement Components: publisher Versions: 3.2.0 Reporter: Graham Dumpleton Priority: Minor Fix For: 3.2.0 Attachments: util.diff.txt Cut and paste of idea presented on mailing list. See: http://www.mail-archive.com/python-dev@httpd.apache.org/msg00294.html Have a strange patch here for consideration. In CherryPy, one can manually construct the page hierarchy by writing: cpg.root.onepage = OnePage() cpg.root.otherpage = OtherPage() cpg.root.some = Page() cpg.root.some.page = Page() The closest equivalent to this in mod_python is the publisher handler, whereby a URL will be mapped to attributes and member functions of a class. One generally though has to create an actual class to encapsulate all the bits together. One can to a degree with publisher create a mapping without creating a proper class by using: class _Mapping: pass def _method1(): return _method1 def _method2(): return _method2 object = _Mapping() object.onepage = _method1 object.otherpage = _method2 What isn't possible though without creating a real class is have a normal function which is called when the dummy mapping object itself is the target. Ie., following does not work: object.__call__ = _method1 This is because util.apply_fs_data() assumes that __call__() is always an object method. I know this is sort of an abuse of __call__(), but it does actually work in Python itself, just not in mod_python when URLs are mapped to object. class A: ... pass ... def _method(): ... return method ... a=A() a.__call__ = _method a() 'method' Anyway, I have attached a patch which would allow this sort of thing to actually work within mod_python. I feel it could be a useful way of quickly constructing special object hierarchies from other functions, objects and attributes without having to actually create real classes. For example: def _method(): return method class _Mapping: pass _subdir1 = _Mapping() _subdir1.__call__ = _method # .../root/subdir1 _subdir1.page1 = _method # .../root/subdir1/page1 _subdir1.page2 = _method # .../root/subdir1/page2 root = _Mapping() root.__call__ = _method # .../root root.page1 = _method # .../root/page1 root.subdir1 = _subdir1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MODPYTHON-73) Using objects to create an explicit hierarchy.
[ http://issues.apache.org/jira/browse/MODPYTHON-73?page=comments#action_12320768 ] Nicolas Lehuen commented on MODPYTHON-73: - BTW Graham, after I wrote the unit test, I remembered that your patch should not be needed. With the new publisher, the hierarchy traversal is taken care of at the publisher level, and apply_fs_data don't have to worry about it. Indeed, I've reverted your patch on my working copy and ran the new unit test, and mod_python behaved as you want without changing anything to apply_fs_data. Unless I missed something in your enhancement request ? Using objects to create an explicit hierarchy. -- Key: MODPYTHON-73 URL: http://issues.apache.org/jira/browse/MODPYTHON-73 Project: mod_python Type: Improvement Components: publisher Versions: 3.2.0 Reporter: Graham Dumpleton Priority: Minor Fix For: 3.2.0 Attachments: util.diff.txt Cut and paste of idea presented on mailing list. See: http://www.mail-archive.com/python-dev@httpd.apache.org/msg00294.html Have a strange patch here for consideration. In CherryPy, one can manually construct the page hierarchy by writing: cpg.root.onepage = OnePage() cpg.root.otherpage = OtherPage() cpg.root.some = Page() cpg.root.some.page = Page() The closest equivalent to this in mod_python is the publisher handler, whereby a URL will be mapped to attributes and member functions of a class. One generally though has to create an actual class to encapsulate all the bits together. One can to a degree with publisher create a mapping without creating a proper class by using: class _Mapping: pass def _method1(): return _method1 def _method2(): return _method2 object = _Mapping() object.onepage = _method1 object.otherpage = _method2 What isn't possible though without creating a real class is have a normal function which is called when the dummy mapping object itself is the target. Ie., following does not work: object.__call__ = _method1 This is because util.apply_fs_data() assumes that __call__() is always an object method. I know this is sort of an abuse of __call__(), but it does actually work in Python itself, just not in mod_python when URLs are mapped to object. class A: ... pass ... def _method(): ... return method ... a=A() a.__call__ = _method a() 'method' Anyway, I have attached a patch which would allow this sort of thing to actually work within mod_python. I feel it could be a useful way of quickly constructing special object hierarchies from other functions, objects and attributes without having to actually create real classes. For example: def _method(): return method class _Mapping: pass _subdir1 = _Mapping() _subdir1.__call__ = _method # .../root/subdir1 _subdir1.page1 = _method # .../root/subdir1/page1 _subdir1.page2 = _method # .../root/subdir1/page2 root = _Mapping() root.__call__ = _method # .../root root.page1 = _method # .../root/page1 root.subdir1 = _subdir1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MODPYTHON-76) input filter hangs in combination with mod_proxy
input filter hangs in combination with mod_proxy Key: MODPYTHON-76 URL: http://issues.apache.org/jira/browse/MODPYTHON-76 Project: mod_python Type: Bug Components: core Versions: 3.1.4, 3.2.0 Environment: Linux, Apache 2.024 and unreleased Apache 2.0.x svn version. Reporter: Martijn Faassen Input filters hang when mod_proxy is in use. Other behavior seen is infinite calls of the input filter function even though the data has already been processed. In Apache 2.0.24, this problem seems to be fundamental; I have no way to get rid of the hang, except perhaps in the case of an input filter that does not change the size of the passed-through data. In svn Apache, the problem goes away as soon as I remove the filter.flush() in apache.py's FilterDispatch handler. svn Apache does according to its changelog contain a fix to mod_proxy's handling of input filters. For my application, use of mod_proxy is essential, as mod_python is essentially proxying another web server process. Output filters do not seem to be affected by the presence of filter.flush(), and in fact filter.flush() is important to make sure memory use remains small when handling large amounts of data being outputted by the server. All of this is rather hairy and I don't know quite what to blame; part of this seems indeed due to Apache itself, but perhaps not everything. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MODPYTHON-73) Using objects to create an explicit hierarchy.
[ http://issues.apache.org/jira/browse/MODPYTHON-73?page=comments#action_12320781 ] Graham Dumpleton commented on MODPYTHON-73: --- Note that util.apply_fs_data() can be called directly independent of mod_python.publisher. Thus it may be redundant within the context of mod_python.publisher but still useful as a separate change when the function is used directly, which is what I had in mind for it. Using objects to create an explicit hierarchy. -- Key: MODPYTHON-73 URL: http://issues.apache.org/jira/browse/MODPYTHON-73 Project: mod_python Type: Improvement Components: publisher Versions: 3.2.0 Reporter: Graham Dumpleton Priority: Minor Fix For: 3.2.0 Attachments: util.diff.txt Cut and paste of idea presented on mailing list. See: http://www.mail-archive.com/python-dev@httpd.apache.org/msg00294.html Have a strange patch here for consideration. In CherryPy, one can manually construct the page hierarchy by writing: cpg.root.onepage = OnePage() cpg.root.otherpage = OtherPage() cpg.root.some = Page() cpg.root.some.page = Page() The closest equivalent to this in mod_python is the publisher handler, whereby a URL will be mapped to attributes and member functions of a class. One generally though has to create an actual class to encapsulate all the bits together. One can to a degree with publisher create a mapping without creating a proper class by using: class _Mapping: pass def _method1(): return _method1 def _method2(): return _method2 object = _Mapping() object.onepage = _method1 object.otherpage = _method2 What isn't possible though without creating a real class is have a normal function which is called when the dummy mapping object itself is the target. Ie., following does not work: object.__call__ = _method1 This is because util.apply_fs_data() assumes that __call__() is always an object method. I know this is sort of an abuse of __call__(), but it does actually work in Python itself, just not in mod_python when URLs are mapped to object. class A: ... pass ... def _method(): ... return method ... a=A() a.__call__ = _method a() 'method' Anyway, I have attached a patch which would allow this sort of thing to actually work within mod_python. I feel it could be a useful way of quickly constructing special object hierarchies from other functions, objects and attributes without having to actually create real classes. For example: def _method(): return method class _Mapping: pass _subdir1 = _Mapping() _subdir1.__call__ = _method # .../root/subdir1 _subdir1.page1 = _method # .../root/subdir1/page1 _subdir1.page2 = _method # .../root/subdir1/page2 root = _Mapping() root.__call__ = _method # .../root root.page1 = _method # .../root/page1 root.subdir1 = _subdir1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MODPYTHON-73) Using objects to create an explicit hierarchy.
[ http://issues.apache.org/jira/browse/MODPYTHON-73?page=comments#action_12320783 ] Graham Dumpleton commented on MODPYTHON-73: --- I checked again, you mustn't have it quite right as it definitely fails for me. Eg: def index(): return html/bodypXOX/p/body/html class _Dummy: pass dummy = _Dummy() dummy.__call__ = index When I use URL /~grahamd/mp32/page/dummy I get: Mod_python error: PythonHandler mod_python.publisher Traceback (most recent call last): File /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/apache.py, line 299, in HandlerDispatch result = object(req) File /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/publisher.py, line 213, in handler published = publish_object(req, object) File /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/publisher.py, line 410, in publish_object return publish_object(req,util.apply_fs_data(object, req.form, req=req)) File /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/util.py, line 398, in apply_fs_data fc = object.__call__.im_func.func_code AttributeError: 'function' object has no attribute 'im_func' With the fix I suggested, it works. If I import the file into Python command line, can call it okay: import page page.dummy() 'html/bodypXOX/p/body/html' So it is valid to do in Python. Using objects to create an explicit hierarchy. -- Key: MODPYTHON-73 URL: http://issues.apache.org/jira/browse/MODPYTHON-73 Project: mod_python Type: Improvement Components: publisher Versions: 3.2.0 Reporter: Graham Dumpleton Priority: Minor Fix For: 3.2.0 Attachments: util.diff.txt Cut and paste of idea presented on mailing list. See: http://www.mail-archive.com/python-dev@httpd.apache.org/msg00294.html Have a strange patch here for consideration. In CherryPy, one can manually construct the page hierarchy by writing: cpg.root.onepage = OnePage() cpg.root.otherpage = OtherPage() cpg.root.some = Page() cpg.root.some.page = Page() The closest equivalent to this in mod_python is the publisher handler, whereby a URL will be mapped to attributes and member functions of a class. One generally though has to create an actual class to encapsulate all the bits together. One can to a degree with publisher create a mapping without creating a proper class by using: class _Mapping: pass def _method1(): return _method1 def _method2(): return _method2 object = _Mapping() object.onepage = _method1 object.otherpage = _method2 What isn't possible though without creating a real class is have a normal function which is called when the dummy mapping object itself is the target. Ie., following does not work: object.__call__ = _method1 This is because util.apply_fs_data() assumes that __call__() is always an object method. I know this is sort of an abuse of __call__(), but it does actually work in Python itself, just not in mod_python when URLs are mapped to object. class A: ... pass ... def _method(): ... return method ... a=A() a.__call__ = _method a() 'method' Anyway, I have attached a patch which would allow this sort of thing to actually work within mod_python. I feel it could be a useful way of quickly constructing special object hierarchies from other functions, objects and attributes without having to actually create real classes. For example: def _method(): return method class _Mapping: pass _subdir1 = _Mapping() _subdir1.__call__ = _method # .../root/subdir1 _subdir1.page1 = _method # .../root/subdir1/page1 _subdir1.page2 = _method # .../root/subdir1/page2 root = _Mapping() root.__call__ = _method # .../root root.page1 = _method # .../root/page1 root.subdir1 = _subdir1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MODPYTHON-73) Using objects to create an explicit hierarchy.
[ http://issues.apache.org/jira/browse/MODPYTHON-73?page=comments#action_12320795 ] Nicolas Lehuen commented on MODPYTHON-73: - OK, the unit test I performed was not exactly what you meant : class Mapping(object): def __init__(self,name): self.name = name def __call__(self,req): return Called %s%self.name hierarchy_root = Mapping(root); hierarchy_root.page1 = Mapping(page1) hierarchy_root.page1.subpage1 = Mapping(subpage1) hierarchy_root.page2 = Mapping(page2) This worked before your patch and still works after, but that wasn't what you meant. I've added a new unit test to match your needs : class Mapping2: pass hierarchy_root_2 = Mapping2() hierarchy_root_2.__call__ = index hierarchy_root_2.page1 = index hierarchy_root_2.page2 = index And indeed, your patch is required for this to work. Using objects to create an explicit hierarchy. -- Key: MODPYTHON-73 URL: http://issues.apache.org/jira/browse/MODPYTHON-73 Project: mod_python Type: Improvement Components: publisher Versions: 3.2.0 Reporter: Graham Dumpleton Priority: Minor Fix For: 3.2.0 Attachments: util.diff.txt Cut and paste of idea presented on mailing list. See: http://www.mail-archive.com/python-dev@httpd.apache.org/msg00294.html Have a strange patch here for consideration. In CherryPy, one can manually construct the page hierarchy by writing: cpg.root.onepage = OnePage() cpg.root.otherpage = OtherPage() cpg.root.some = Page() cpg.root.some.page = Page() The closest equivalent to this in mod_python is the publisher handler, whereby a URL will be mapped to attributes and member functions of a class. One generally though has to create an actual class to encapsulate all the bits together. One can to a degree with publisher create a mapping without creating a proper class by using: class _Mapping: pass def _method1(): return _method1 def _method2(): return _method2 object = _Mapping() object.onepage = _method1 object.otherpage = _method2 What isn't possible though without creating a real class is have a normal function which is called when the dummy mapping object itself is the target. Ie., following does not work: object.__call__ = _method1 This is because util.apply_fs_data() assumes that __call__() is always an object method. I know this is sort of an abuse of __call__(), but it does actually work in Python itself, just not in mod_python when URLs are mapped to object. class A: ... pass ... def _method(): ... return method ... a=A() a.__call__ = _method a() 'method' Anyway, I have attached a patch which would allow this sort of thing to actually work within mod_python. I feel it could be a useful way of quickly constructing special object hierarchies from other functions, objects and attributes without having to actually create real classes. For example: def _method(): return method class _Mapping: pass _subdir1 = _Mapping() _subdir1.__call__ = _method # .../root/subdir1 _subdir1.page1 = _method # .../root/subdir1/page1 _subdir1.page2 = _method # .../root/subdir1/page2 root = _Mapping() root.__call__ = _method # .../root root.page1 = _method # .../root/page1 root.subdir1 = _subdir1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Getting ready for 3.2 beta 2
Or speaking in diff (not tested):
--- setup.py.in.orig2005-09-01 11:42:09.082202944 -0400
+++ setup.py.in 2005-09-01 11:44:35.969872624 -0400
@@ -140,18 +140,24 @@
# this is a hack to prevent build_ext from trying to append
initmod_python to the export symbols
self.export_symbols = finallist(self.export_symbols)
-ModPyModule = ModPyExtension(getmp_srcdir(), [getmp_includedir(),
getapache_includedir()], [getapache_libdir()])
if winbuild:
+
+# build mod_python.so
+ModPyModule = ModPyExtension(getmp_srcdir(), [getmp_includedir(),
getapache_includedir()], [getapache_libdir()])
+
scripts = [win32_postinstall.py]
# put the mod_python.so file in the Python root ...
# win32_postinstall.py will pick it up from there...
# data_files = [(, [(os.path.join(getmp_srcdir(), 'Release',
'mod_python.so'))])]
data_files = []
+ext_modules = [ModPyModule, PSPModule]
+
else:
-# mpso = ../src/mod_python.so
+
scripts = []
data_files = []
+ext_modules = [PSPModule]
import string
from distutils import sysconfig
@@ -174,7 +180,7 @@
package_dir={'mod_python': os.path.join(getmp_rootdir(), 'lib',
'python', 'mod_python')},
scripts=scripts,
data_files=data_files,
- ext_modules=[ModPyModule, PSPModule])
+ ext_modules=ext_modules)
# makes emacs go into python mode
### Local Variables:
On Thu, 1 Sep 2005, Gregory (Grisha) Trubetskoy wrote:
On Wed, 31 Aug 2005, Jim Gallacher wrote:
3. Eliminate creation of mod_python_so.so in non-windows environments.
Fix is ready to commit.
Not Done. I decided to defer this for reasons I won't go into just now.
It is not a show stopper anyway.
Isn't the fix basically just placing the ModPyModule and setup() with
ModPyModule inside the if winbuild block and then having another set()
without the ModPyModule in the else clause?
Unless there is some good reason for it, I think it is a show stopper because
it makes the build process look a bit on the bizzare side on Unix.
Grisha
