http://permalink.gmane.org/gmane.comp.apache.mod-python.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.apache.mod-python.devel/4319 <pre>A heads up for the Quetzalcoalt + mod_python user community that the Quetzalcoatl project has been 'moved to the Attic'. This means that the Quetzalcoatl developers (more formally its Project Management Committee) have voted to retire Quetzalcoatl and move the responsibility for its oversight over to the Attic project. Loosely speaking this means that the projects resources will be moved to a read-only state. You can read more about the Apache Attic and the process of moving to the Attic at http://attic.apache.org. You can follow this process in JIRA: https://issues.apache.org/jira/browse/ATTIC-67 Thanks, Hen on behalf of Quetzalcoatl + the Attic. </pre> Henri Yandell 2010-07-17T06:48:30 http://permalink.gmane.org/gmane.comp.apache.mod-python.devel/4318 <pre>md5 module is deprecated; use hashlib instead --------------------------------------------- Key: MODPYTHON-257 URL: https://issues.apache.org/jira/browse/MODPYTHON-257 Project: mod_python Issue Type: Bug Affects Versions: 3.3.1 Environment: ubuntu linux / python 2.6 Reporter: Forest mod_python is spewing a lot of log spam: [Thu May 27 15:08:00 2010] [error] /usr/lib/python2.6/dist-packages/mod_python/importer.py:32: DeprecationWarning: the md5 module is deprecated; use hashlib instead </pre> Forest (JIRA 2010-05-27T22:23:41 http://permalink.gmane.org/gmane.comp.apache.mod-python.devel/4316 <pre>Would it make sense to switch mod_python to always use unicode, as it is now, publisher supports unicode content, but req.write and FieldList does use bytestrings. /Anders </pre> Anders Blomdell 2010-03-05T08:59:01 http://permalink.gmane.org/gmane.comp.apache.mod-python.devel/4315 <pre> It likely was originally meant to mirror cgi.FieldStorage used for CGI scripts and so carried across same level of functionality. Graham </pre> Graham Dumpleton 2010-03-02T09:28:03 http://permalink.gmane.org/gmane.comp.apache.mod-python.devel/4314 <pre>Done If this is really the case, the interface is bloated :-) The age of last version hinted that... /Anders </pre> Anders Blomdell 2010-03-02T08:32:27 http://permalink.gmane.org/gmane.comp.apache.mod-python.devel/4313 <pre> [ https://issues.apache.org/jira/browse/MODPYTHON-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Blomdell updated MODPYTHON-256: -------------------------------------- Attachment: modpython.patch Add new method to delete a named field from FieldList and use it in __setitem__/__delitem__ </pre> Anders Blomdell (JIRA 2010-03-02T08:29:27 http://permalink.gmane.org/gmane.comp.apache.mod-python.devel/4312 <pre>util.FieldStorage __setitem__/__delitem__ might affect wrong field ------------------------------------------------------------------ Key: MODPYTHON-256 URL: https://issues.apache.org/jira/browse/MODPYTHON-256 Project: mod_python Issue Type: Bug Components: core Affects Versions: 3.3.1 Environment: Any Reporter: Anders Blomdell When a FieldStorage has two (or more) Filed instances with the same value but different names, the behaviour of programs like this is (more or less) undefined: fs = util.FieldStorage(req) fs['id1'] = 'New value' del fs['id2'] The reason for the undefinedness, is this code in __delitem__ (and the similar in __setitem__): table = self.list.table() values = table[key] for value in values: self.list.remove(value) What happens is that the self.list.remove(value) will remove the first field with a matching value, regardless of that fields name. Here is</pre> Anders Blomdell (JIRA 2010-03-02T08:25:27 http://permalink.gmane.org/gmane.comp.apache.mod-python.devel/4311 <pre>I agree with Graham on all points. And may be this is a good chance for us to start checking some stuff in after this long while.... :) Grisha On Mon, Mar 1, 2010 at 5:41 PM, Graham Dumpleton &lt;graham.dumpleton&lt; at &gt;gmail.com </pre> Grisha Trubetskoy 2010-03-01T22:56:07 http://permalink.gmane.org/gmane.comp.apache.mod-python.devel/4310 <pre>Please log a bug report at: https://issues.apache.org/jira/browse/MODPYTHON No one else has likely found this because deleting stuff out of FieldStorage is not the norm. People would normally translate the contents into some other data structure and manipulate it there. Do note that there has been no active development on mod_python for quite a long time, so don't expect to see any updated version until someone new decides to take ownership of the project. Graham On 2 March 2010 02:04, Anders Blomdell &lt;anders.blomdell&lt; at &gt;control.lth.se&gt; wrote: </pre> Graham Dumpleton 2010-03-01T22:41:15 http://permalink.gmane.org/gmane.comp.apache.mod-python.devel/4309 <pre> Some more thinking made me come up with the patch below. Regards Anders --- /usr/lib/python2.6/site-packages/mod_python/util.py.orig 2006-11-22 12:15:54.000000000 +0100 +++ /usr/lib/python2.6/site-packages/mod_python/util.py 2010-03-01 16:00:30.000000000 +0100 &lt; at &gt;&lt; at &gt; -145,6 +145,12 &lt; at &gt;&lt; at &gt; self.__table[item.name] = [item] return self.__table + def delete_name(self, name): + self.__table = None + for i in range(len(self) - 1, -1, -1): + if self[i].name == name: + self.pop(i) + def __delitem__(self, *args): self.__table = None return list.__delitem__(self, *args) &lt; at &gt;&lt; at &gt; -348,11 +354,8 &lt; at &gt;&lt; at &gt; self.list.append(item) def __setitem__(self, key, value): - table = self.list.table() - if table.has_key(key): - items = table[key] - for item in items: - self.list.remove(item) + if self.list.table().has_key(key): + self.list.delete_name(key) </pre> Anders Blomdell 2010-03-01T15:04:15 http://permalink.gmane.org/gmane.comp.apache.mod-python.devel/4308 <pre>Hi, When a FieldStorage has two (or more) Filed instances with the same value but different names, the behaviour of programs like this is (more or less) undefined: fs = util.FieldStorage(req) fs['id1'] = 'New value' del fs['id2'] The reason for the undefinedness, is this code in __delitem__ (and the similar in __setitem__): table = self.list.table() values = table[key] for value in values: self.list.remove(value) What happens is that the self.list.remove(value) will remove the first field with a matching value, regardless of that fields name. Here is an example from real life: form.clear() form['id1'] = 'x' form['id2'] = 'x' form['id3'] = 'x' # Form now contains {'id2': [Field('id2', 'x')], # 'id3': [Field('id3', 'x')], # 'id1': [Field('id1', 'x')]} form['id2'] = 'y' # Form now contains {'id2': [Field('id2', 'x'), Field('id2', 'y')], # 'id3': [Field('id3', 'x')]} </pre> Anders Blomdell 2010-03-01T11:34:45 http://permalink.gmane.org/gmane.comp.apache.mod-python.devel/4305 <pre>Do you have a year-end hole in your training budget? Or will the improved economy let you finally attend a work conference? Come to sunny and warm Atlanta in February for PyCon 2010. Early bird registration ends on January 6. Register: https://us.pycon.org/2010/register/ See the talks: http://us.pycon.org/2010/conference/talks/ Get trained at a tutorial: http://us.pycon.org/2010/tutorials/ Also see the five (or more!) talks that people can't miss at PyCon: PyOraGeek: PyCon pre-favorites &lt;http://catherinedevlin.blogspot.com/2009/11/pycon-pre-favorites.html&gt; Pyright: PyCon pre-favorites, the Carl T. edition: &lt;http://pyright.blogspot.com/2009/11/pycon-2010-pre-favorites-carl-t-edition.html&gt; Aftermarket Pipes: Five Pycon 2010 Talks I Need to See: &lt;http://apipes.blogspot.com/2009/12/five-pycon-2010-talks-i-need-to-see.html&gt; Jessenoller.com: PyCon 2010: Talks I want to see: &lt;http://jessenoller.com/2009/12/06/pycon-2010-talks-i-want-to-see-keynotes-registration-open/&gt; The Third Bit: Five PyCon Talks I Want</pre> VanL 2009-12-29T17:32:34 http://permalink.gmane.org/gmane.comp.apache.mod-python.devel/4304 <pre> [ https://issues.apache.org/jira/browse/MODPYTHON-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=12768965#action_12768965 ] Graham Dumpleton commented on MODPYTHON-235: -------------------------------------------- Have no access to www.modpython.org to make changes. </pre> Graham Dumpleton (JIRA 2009-10-22T23:19:59 http://permalink.gmane.org/gmane.comp.apache.mod-python.devel/4303 <pre> [ https://issues.apache.org/jira/browse/MODPYTHON-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=12768681#action_12768681 ] Michael P. Soulier commented on MODPYTHON-235: ---------------------------------------------- Understood. It might help to update http://www.modpython.org/ with this information. Thank you, Mike </pre> Michael P. Soulier (JIRA 2009-10-22T13:35:59 http://permalink.gmane.org/gmane.comp.apache.mod-python.devel/4302 <pre> [ https://issues.apache.org/jira/browse/MODPYTHON-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=12768559#action_12768559 ] Graham Dumpleton commented on MODPYTHON-235: -------------------------------------------- No plans to fix it. No plans for any work to be done on mod_python by anyone. The fix as described also isn't sufficient anyway as Python itself leaks memory even when Py_Initialize() is called. For mod_python 3.X that is by design. For Python 2.X, which is all mod_python supports anyway, not clear if the memory leaks in Python are by design or unintended. Could perhaps be a mix of both. If you are using mod_python purely for purposes of hosting a Python web application which also has a WSGI interface, you should consider moving to mod_wsgi. The mod_wsgi package ensure that Py_Finalize() is called and so that aspect of leak doesn't exist. There is still the issue with Python itself leaking, but in mod_wsgi 3.X that is avoided by delaying initial</pre> Graham Dumpleton (JIRA 2009-10-22T04:14:59 http://permalink.gmane.org/gmane.comp.apache.mod-python.devel/4301 <pre> [ https://issues.apache.org/jira/browse/MODPYTHON-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=12768547#action_12768547 ] Michael P. Soulier commented on MODPYTHON-235: ---------------------------------------------- Is anyone planning to fix this issue? It's hitting a product that I work on that performs graceful restarts on apache regularly. If the solution above works, would the fix not be simple? This issue is 2 years old. </pre> Michael P. Soulier (JIRA 2009-10-22T02:53:59 http://permalink.gmane.org/gmane.comp.apache.mod-python.devel/4300 <pre> [ https://issues.apache.org/jira/browse/MODPYTHON-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=12764257#action_12764257 ] Brian Martin commented on MODPYTHON-135: ---------------------------------------- CVE-2006-1095 </pre> Brian Martin (JIRA 2009-10-09T23:48:31 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.apache.mod-python.devel