[Zope-Coders] Confusing code in ObjectManager manage_FTPstat
Found some lovely piece of code deep into the FTP parts of Zope 2 last saturday, one of them is truely ugly. It's listing the contents of the current and parent folders for no apparent reason (or at least, it didn't make sense either to me or Chris McDonough). The code in question is in the ``manage_FTPstat`` method of ``OFS.ObjectManager``. Tracing back the source of this code, it seems to have been (surprisingly) introduced by Jim Fulton, back in 1999. [1] Later on, Amos Latteier changed part of the code (namely ``manage_FTPlist``) to use a slightly more friendlier, yet equally confusing ``is_acquired`` method. [2] I'm now sitting here, trying to make sense of this code and wondering what was the original intention in the first place. Would anyone have a clue? [1] http://tinyurl.com/86upc [2] http://tinyurl.com/9adc5 -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ Zope-Coders mailing list Zope-Coders@zope.org http://mail.zope.org/mailman/listinfo/zope-coders
Re: [Zope-Coders] Re: Confusing code in ObjectManager manage_FTPstat
On Mon, Oct 31, 2005 at 10:05:45AM -0500, Jim Fulton wrote: | Sidnei da Silva wrote: | Found some lovely piece of code deep into the FTP parts of Zope 2 last | saturday, one of them is truely ugly. It's listing the contents of | the current and parent folders for no apparent reason (or at least, it | didn't make sense either to me or Chris McDonough). | | There's a comment stating the intent. Yes, but the original code does the check in a truely obscure way, at least to me. I've thought of spelling: # check to see if we are acquiring our objectValues or not if not (len(REQUEST.PARENTS) 1 and self.objectValues() == REQUEST.PARENTS[1].objectValues()): As: if self.objectValues.im_self is not self: However I'm not sure that would be the be the correct replacement. There doesn't seem to exist any test for this. | The code in question is in the ``manage_FTPstat`` method of | ``OFS.ObjectManager``. Tracing back the source of this code, it seems | to have been (surprisingly) introduced by Jim Fulton, back in | 1999. [1] | | Later on, Amos Latteier changed part of the code (namely | ``manage_FTPlist``) to use a slightly more friendlier, yet equally | confusing ``is_acquired`` method. [2] | | I'm now sitting here, trying to make sense of this code and wondering | what was the original intention in the first place. Would anyone have | a clue? | | I think the comments make this pretyu clear. The intent is to avoid | providing listings of acquired objects. In fact, the intent of both | bits of code, I think is to prevent FTP access to acquired objects. Wouldn't that be better implemented by making the same check as it's done for WebDAV and set 'maybe_webdav_client' (abusing the name) so that it sets the 'no_acquire_flag'? | I suspect that there is a clearer way to implement the intent. I have three suggestions right now: 1. change manage_FTPstat to use the same thing as manage_FTPlist (using App.Common.is_acquired, and possibly rewriting is_acquired to a simpler check) OR 2. Throw away the `is_acquired` check and replace it by a much simpler check OR 3. Setting 'maybe_webdav_client' in the request object so the object is never acquired for FTP, the same way as it's done for WebDAV. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ Zope-Coders mailing list Zope-Coders@zope.org http://mail.zope.org/mailman/listinfo/zope-coders
Re: [Zope-Coders] Issue 1891
On Sat, Sep 17, 2005 at 11:02:45AM +0200, Jens Vagelpohl wrote: | I'm all for removing deprecated stuff like that, the sticky point is | removing it in places that immediately breaks users' own scripts. You | can't do that within the 2.8 release cycle, sites breaking from one | third-dot release to the next is clearly a problem. | | Can we handle the deprecation like other deprecations so far? For the | next release line, meaning Zope 2.9, emit deprecation warnings when | users have scripts with whrandom in Zope, and kill it completely in | 2.10. On the other hand, all places where Zope uses whrandom | *internally* that don't have anything to do with user code could | probably be cleaned up right away. I'm sure that can be done, probably by making whrandom import lazy in the context of DTML methods and Python Scripts? (ie: just import when it's used). I lack the time and knowledge to do that right now though. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ Zope-Coders mailing list Zope-Coders@zope.org http://mail.zope.org/mailman/listinfo/zope-coders
[Zope-Coders] Issue 1891
Issue 1891 has a patch to remove some references to the 'whrandom' module, that has been deprecated since python2.1. I've cleaned up that patch and expanded it to remove *all* references to whrandom, including code that enabled it for use by 'Script (Python)' and DTML. It's my opinion that people using 'whrandom' explicitly should know what they are doing and won't be harmed too much by the removal of this. Any thoughts? -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ Zope-Coders mailing list Zope-Coders@zope.org http://mail.zope.org/mailman/listinfo/zope-coders
Re: [Zope-Coders] Wrong username and password == Anonymous User?
On Fri, Apr 22, 2005 at 09:11:28AM +0100, Chris Withers wrote: | Sidnei da Silva wrote: | | Well, my use-case is actually for WebDAV. So you won't just visit a | different part of the site at random. I'm currently trying to | understand if this would be a problem for WebDAV too. | | Nevertheless, since you're in the code alrady, can you add the big | comment explaining why it is like it is? | (or tell me a file and line number so I can do it) There's a patch attached to the first message of the thread. -- Sidnei da Silva [EMAIL PROTECTED] http://awkly.org - dreamcatching :: making your dreams come true http://www.enfoldsystems.com http://plone.org/about/team#dreamcatcher glyph So... glyph XML. *** Quits: dash:#twisted [EMAIL PROTECTED] (Read error: 113 (No route to host)) glyph Wow... just _saying_ it makes him disappear ___ Zope-Coders mailing list Zope-Coders@zope.org http://mail.zope.org/mailman/listinfo/zope-coders
