[Zope3-dev] Re: What does python 3000 mean for zope?
Hermann Himmelbauer wrote: Am Sonntag, 2. September 2007 08:18 schrieb Andreas Jung: --On 1. September 2007 16:21:23 -0400 Stephan Richter [EMAIL PROTECTED] wrote: On Saturday 01 September 2007 15:33, Martijn Faassen wrote: I think Zope will be on Python 2.x for many years to come. I really hope not. A friend of mine and I want to get a bit involved in Python 3000 once it is stable enough that the standard libs can get some attention. At this point I really want to have an initial look at porting Zope 3 packages to Python 3. I really hope we can move to Python 3 in a reasonable amount of time. What are the major benefits from moving to Python 3? The major and most important change I see in Py3K is the string-as-unicode implementation. That's a big advantage. However everything else is in some way syntactical sugar. Py3k still won't run on multiple CPUs, it still uses the GIL... improvements in this area would be arguments for me to move to Py3K. Only speaking for my self, I don't see major improvements that would my daily Python experience significantly. I personally have the same impression. The string-as-unicode implementation is a real advantage, moreover I also like many of the syntactic changes. What I would like to see, however, is a native implementation of interfaces, which seems not really to be the case. Moreover, as you stated above, Python 3 will still use the GIL, which is a shame, as it's still a uni-processor language. This should be the #1 problem to be addressed, as multi-processor systems are now coming up so fast, however, it seems this is postponed to Python 4000. :-( That's the real problem I see, as in ~ 4 years 8-core systems may be standard and Python 2/3 will only be capable of using 1/8 of the processing power. Best Regards, Hermann Zope's solution to this (multiple processes, ZEO) seems eminently sensible, it's a lot less hard on the brain than multithreading and it works now. Laurence ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: calling interface returns object, calling queryAdapter returns None?
Chris Withers wrote: Hot on the heels of my multi-adapter problem: http://mail.zope.org/pipermail/zope3-dev/2007-January/021600.html ...which I'm still waiting for guidance on, I now find that queryAdapter and calling an interface behave unexpectedly differently in the case where an object directly implements an interface: from zope.interface import Interface,implements class ITest(Interface): pass ... class Test: ... implements(ITest) ... t = Test() ITest(t) __main__.Test instance at 0x01C6E300 from zope.component import queryAdapter queryAdapter(t,ITest) How come calling the interface returns t but queryAdapter returns None? Should I log this and my previous multi-adapter example as bugs in the collector? cheers, Chris From the Interface.__call__ docstring: If an object already implements the interface, then it will be returned queryAdapter is looking in the adapter registry. You have not registered any adapters. So this looks like the expected behaviour to me. Laurence ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] making ldapadapter search into a generator and support sizelimit
Hi there,
I've run into a few problems with using ldapadapter with large search
results taking a long time. The attached patch makes LDAPAdapter.search
support ldap.LDAPObject.searc_ext's sizelimit parameter, and also turns
the method into a generator, so partial search results (i.e. when you
specify searchlimit) get returned.
This is an important feature for working with large ldap servers, but
I'm unsure if this change could cause problems for current users of
ldapadapter. Perhaps I should put the extra functionality it a new
method (itersearch perhaps)? Anyway, I do not currently have checking
priveliges so I shall defer to someone who does to make a decision ;-)
Laurence
Index: tests/fakeldap.py
===
--- tests/fakeldap.py (revision 65768)
+++ tests/fakeldap.py (working copy)
@@ -159,6 +159,31 @@
raise NO_SUCH_OBJECT
return res
+def search_ext(self, base, scope=SCOPE_SUBTREE, filter='(objectClass=*)',
+ attrs=[], sizelimit=0):
+#
+# Async search
+#
+self._sizelimit = sizelimit
+self._async_results = self.search_s(base, scope, filter, attrs)
+self._async_counter = 0
+return 1 # result msgid (unused here)
+
+def result(self, msgid=1, all=1):
+#
+# Retrieve result from the async result list
+#
+if all:
+return (101, self._async_results[self._async_counter:])
+else:
+try:
+r = self._async_results[self._async_counter]
+self._async_counter += 1
+return (100, [r])
+except IndexError:
+return (101, [])
+
+
def modify_s(self, dn, mod_list):
dnl = tuple(dn.split(','))
entry = the_data.get(dnl)
Index: interfaces.py
===
--- interfaces.py (revision 65768)
+++ interfaces.py (working copy)
@@ -134,7 +134,8 @@
May raise NoSuchObject.
-def search(base, scope='one', filter='(objectClass=*)', attrs=None):
+def search(base, scope='one', filter='(objectClass=*)', attrs=None,
+ sizelimit=0):
Search an LDAP server.
- base is a unicode dn.
@@ -146,7 +147,12 @@
- attrs may be a list of entry attributes to return, or None to
return them all.
-Returns a sequence of (dn, entry), where dn is unicode and entry
+- sizelimit is the client-side search limit. If non-zero not more than
+ sizelimit results are returned by the server. If there exist more
than
+ sizelimit results then ldap.SIZELIMIT_EXCEEDED will be raised when
+ iterating to the sizelimit+1 result.
+
+Returns an iterator of (dn, entry), where dn is unicode and entry
is a mapping whose values are lists of unicode strings.
May raise NoSuchObject.
Index: utility.py
===
--- utility.py (revision 65768)
+++ utility.py (working copy)
@@ -94,7 +94,7 @@
def modify(self, dn, entry):
# Get current entry
-res = self.search(dn, 'base')
+res = list(self.search(dn, 'base'))
if not res:
raise interfaces.NoSuchObject(dn)
cur_dn, cur_entry = res[0]
@@ -119,7 +119,7 @@
self.conn.modify_s(dn.encode('utf-8'), mod_list)
def search(self, base, scope='sub', filter='(objectClass=*)',
- attrs=None):
+ attrs=None, sizelimit=0):
# Convert from unicode to UTF-8, and attrs must be ASCII strings.
base = base.encode('utf-8')
scope = convertScope(scope)
@@ -127,25 +127,32 @@
if attrs is not None:
attrs = [str(attr) for attr in attrs]
try:
-ldap_entries = self.conn.search_s(base, scope, filter, attrs)
+result_id = self.conn.search_ext(base, scope, filter, attrs,
+sizelimit=sizelimit)
+# get the results one at a time
+while 1:
+result_type, result_data = self.conn.result(result_id, all=0)
+if result_data == []:
+break
+else:
+# Convert returned values from utf-8 to unicode.
+for dn, entry in result_data: # list should be 1 long
+dn = unicode(dn, 'utf-8')
+for key, values in entry.items():
+# TODO: Can key be non-ascii? Check LDAP spec.
+# FIXME: there may be non-textual binary values.
+try:
+values[:] = [unicode(v, 'utf-8') for v in
values]
+except UnicodeDecodeError:
+# Not all
[Zope3-dev] Re: RFC: Use ConfigParser for High-Level Configuration
I know that everyone here in pythonland seems to hate xml, it may not be pretty, but we have to use it for at least some things anyway. We probably all spend quite a bit of our time writing xhtml, why not just standardize on one format. Please, I don't want to learn any more configuration languages. Laurence Jim Fulton wrote: At: http://dev.zope.org/Zope3/UseConfigParserForHighLevelConfiguration Is a proposal for using ConfigParser, rather than ZConfig for high-level configuration. Comments welcome. Jim ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 web root
I really like this idea. I spend most of my time developing applications with Plone, and am just starting to use zope 3. Most of what I spend my time on is site customisation and one off development. But I've never really found a nice way to layout my applications, Product (or more standard python modules now in zope 3) development doesn't really seem a good fit. With this system I can see my site as: root/ index.zpt (customised homepage, no longer living in the zodb yay!) contacts/ index.zpt contactsdb.zodb projects/ index.zpt projectsdb.zodb ... So I get to move my site customisation to the filesystem in a more natural way than a python module allows. Yes, it looks a bit like an apache site, but hell, I know apache, and I'm building a website :-) As an aside, I've just been doing a little mod_python development and in some ways it seems very natural using it for small applications, but I miss all the zope goodies. I think this could really open up zope 3 to more developers, so a big cheer from me. Laurence Shane Hathaway wrote: An idea just occurred to me. I think others have probably had similar ideas, but didn't express it in the right place or time. Part 1: Let's put an Apache-like web root (similar to /var/www/localhost/htdocs/) in Zope instance homes. It might be called browser or www. Zope will serve pages out of that web root rather than an object database. Part 1 rationale: When people create a Zope instance home, they create some config files and an object database. The root of the site is served out of the object database. To change the default page, newbies are directed to create a default page in the object database. The user didn't ask for an object database. The use of an object database should be a choice, not a requirement. Now the user has to learn some extra tools (fssync, etc.) in order to put the files under version control. I think the user experience for both newbies and experts would be much better if the root of the site were served from a filesystem directory. Part 2: Let's add some ZCML directives that define how to interpret filenames in the web root by their extension. Let's also interpret special per-directory files that map URI names to filenames, similar to Apache .htaccess files. Part 3: One kind of file we can put in the web root serves as a gateway into an object database. We might use the extension .zodb for this purpose. The .zodb file would specify what kind of storage to open, where to find it, and what object to load from it. In a sense, the web root would mount the object database. Some configuration of the web root would mount an object database right at the root, enabling Zope 3 to act just like it does today. Any thoughts or gut reactions? Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Retaining ease of customisation
Jean-Marc, Just trying to understand your scheme here, but taking Martin's example of a current zpt macro, how would I replace the macro with a view and retain the ability to customise it TTW? From my limited understanding of your cps skins package it seems that it is perfect for site managers to customise layout (what goes where) but not the visual design of a site, or have I miusunderstood? Regards, Laurence Jean-Marc Orliaguet wrote: Hi, What I'm claiming is that is that TTW customization is valuable and that Zope3 has to leverage this in a way or in another. What I question is the idea of customizing views. What CPSSkins does is that it allows every resources to be customized TTW, but the view that does the final composition is a standard filesystem view. This is why I'm saying that Zope3 supports this already, provided you don't customize the view but the resources used by the view. This may have been misleading to express it that way, but the goals and the results are the same. When looking at TTW possibilities I started with trying to emulate the portal_skins filesystem directory view approach that is used in Zope2. My conclusion was that only resources, or templates understood as resources need to be customized, the actual view mechanism can stay on the filesystem and it can call the resources instead. can't just a view be created that calls resources (ZPT, etc)? why does the entire view itself have to be customized TTW? Regards /JM Martin Aspeli wrote (only to plone-dev it seems): ... and let me ask a related question: Say in Goldegg we make global_sections or some other site-wide UI element be a Five view. Now, if I, TTW or TTFS (through-the-file-system) want to customise that template beyond what CSS can do, i.e. change its markup, without also changing main_template, which calls it, what's the simplest way of doing that? Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
