[Zope-Checkins] SVN: Zope/trunk/ZOPE_APP_DEPENDENCIES.rst Note status of zope.app.pagetemplate
Log message for revision 106668: Note status of zope.app.pagetemplate Changed: U Zope/trunk/ZOPE_APP_DEPENDENCIES.rst -=- Modified: Zope/trunk/ZOPE_APP_DEPENDENCIES.rst === --- Zope/trunk/ZOPE_APP_DEPENDENCIES.rst2009-12-16 22:26:14 UTC (rev 106667) +++ Zope/trunk/ZOPE_APP_DEPENDENCIES.rst2009-12-16 22:30:11 UTC (rev 106668) @@ -93,6 +93,11 @@ - [_] zope.app.localpermission o zope.app.security +- [_] zope.app.pagetemplate + (this package has no zope.app dependencies of its own anymore and should + be renamed to reflect this or its commonly used parts be extracted) + o zope.viewlet + - [_] zope.app.security * zope.viewlet * zope.traversing ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/ZOPE_APP_DEPENDENCIES.rst Note that basicskin isn't quite as evil anymore
Log message for revision 106675: Note that basicskin isn't quite as evil anymore Changed: U Zope/trunk/ZOPE_APP_DEPENDENCIES.rst -=- Modified: Zope/trunk/ZOPE_APP_DEPENDENCIES.rst === --- Zope/trunk/ZOPE_APP_DEPENDENCIES.rst2009-12-16 22:58:02 UTC (rev 106674) +++ Zope/trunk/ZOPE_APP_DEPENDENCIES.rst2009-12-16 23:02:16 UTC (rev 106675) @@ -72,6 +72,7 @@ * zope.app.twisted - [_] zope.app.basicskin + (this package has no zope.app dependencies of its own anymore) o zope.app.form - [_] zope.app.debug ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/ZOPE_APP_DEPENDENCIES.rst Let's not bother with the transitive dependencies of zope.app.testing, there's actually many more horrors... the real deal is to remove zope.a
Log message for revision 106677: Let's not bother with the transitive dependencies of zope.app.testing, there's actually many more horrors... the real deal is to remove zope.app.testing from the zope.* packages Changed: U Zope/trunk/ZOPE_APP_DEPENDENCIES.rst -=- Modified: Zope/trunk/ZOPE_APP_DEPENDENCIES.rst === --- Zope/trunk/ZOPE_APP_DEPENDENCIES.rst2009-12-16 23:04:05 UTC (rev 106676) +++ Zope/trunk/ZOPE_APP_DEPENDENCIES.rst2009-12-16 23:11:17 UTC (rev 106677) @@ -75,9 +75,6 @@ (this package has no zope.app dependencies of its own anymore) o zope.app.form -- [_] zope.app.debug - o zope.app.testing - - [X] zope.app.dependable * zope.container * zope.app.testing @@ -91,19 +88,16 @@ - [X] zope.app.interface * zope.app.component -- [_] zope.app.localpermission - o zope.app.security - - [_] zope.app.pagetemplate (this package has no zope.app dependencies of its own anymore and should be renamed to reflect this or its commonly used parts be extracted) o zope.viewlet -- [_] zope.app.security +- [X] zope.app.security * zope.viewlet * zope.traversing - o zope.testbrowser - o zope.app.* + * zope.testbrowser + * zope.app.* - [_] zope.app.testing * zope.viewlet @@ -114,4 +108,4 @@ * zope.traversing o zope.testbrowser * zope.site - o zope.app.* + * zope.app.* ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/ZOPE_APP_DEPENDENCIES.rst We are almost there - formlib and functional testbrowser tests are the two last items
Log message for revision 106684: We are almost there - formlib and functional testbrowser tests are the two last items Changed: U Zope/trunk/ZOPE_APP_DEPENDENCIES.rst -=- Modified: Zope/trunk/ZOPE_APP_DEPENDENCIES.rst === --- Zope/trunk/ZOPE_APP_DEPENDENCIES.rst2009-12-16 23:36:05 UTC (rev 106683) +++ Zope/trunk/ZOPE_APP_DEPENDENCIES.rst2009-12-16 23:40:45 UTC (rev 106684) @@ -101,7 +101,7 @@ - [_] zope.app.testing * zope.viewlet - o zope.copypastemve + * zope.copypastemve * zope.error * zope.dublincore o zope.formlib ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope-dev] SVN: zopetoolkit/trunk/ztk.cfg Include distribute, so we can use it in presence of the allow-picked-versions=false
On 12/15/09 11:49 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: Log message for revision 106536: Include distribute, so we can use it in presence of the allow-picked-versions=false Changed: U zopetoolkit/trunk/ztk.cfg -=- Modified: zopetoolkit/trunk/ztk.cfg === --- zopetoolkit/trunk/ztk.cfg2009-12-15 15:33:38 UTC (rev 106535) +++ zopetoolkit/trunk/ztk.cfg2009-12-15 15:41:19 UTC (rev 106536) @@ -250,6 +250,7 @@ # Dependencies: ClientForm = 0.2.10 +distribute = 0.6.10 docutils = 0.5 infrae.subversion = 1.4.5 Jinja2 = 2.1.1 I'm not so sure that we want to push distribute into the ZTK dependencies: can you explain that more clearly? This is in the ztk.cfg, not the setup.py. So it isn't installed per se as a dependency. *If* you're using distribute and configured buildout not to pick versions by hand, this way at least you won't get an error. I suspect there's a setuptools=someversion somewhere in that ztk.cfg, too. Seems safe to me. If zc.buildout is in there, it ought to be 1.4.3, btw, to prevent distribute upgrades from recursing infinitely. Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Tue Dec 15 12:00:00 2009 UTC to Wed Dec 16 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Tue Dec 15 20:38:47 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013203.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue Dec 15 20:40:47 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013204.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Tue Dec 15 20:42:47 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013205.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Tue Dec 15 20:44:47 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013206.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Tue Dec 15 20:46:47 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013207.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Tue Dec 15 20:48:47 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013208.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interfaces vs ZCA concepts
Thomas Lotze wrote: Martijn Faassen wrote: * have dummy implementations in zope.interface that raise NotImplementedError That would still introduce too many zope.component concepts into zope.interface IMO: obviously that of utilities as one of the dummy methods would bear that name, and those of named components and lookup contexts if the methods were to be specified by IInterface. I think having these markers is very important for code readability. People reading the code will otherwise have no idea whatsoever where these methods come from. I'm not sure whether much of a general mechanism is really needed, after all we already have monkey patching (um, sorry Tres, modifying a class). I can see there being an API in zope.interface that allows one to plug into .utility() and .adapt() * have that NotImplementedError say to look for implementations in zope.component I would actually like a mechanism that doesn't care about what package will inject which pieces of API. Do you think such generality is asking too much (at least at this point in time)? I think it will be less clear compared to the methods being there and saying they're injection points intended to be overwritten. Did you make an implicit 'default' deprecated on __call__ yet by the way? Not yet; the other issue looked more interesting so far ;o) BTW, that parameter isn't even called 'default' but 'alternate' in Interface.__call__. The very name of the default argument is another thing that is sneaking from zope.component into zope.component. Let's deprecate 'alternate' and introduce 'default' then. Might actually make the deprecation more easy.. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Compression format for ZTK packages
Hi there, Baiju M wrote: Most of the source distribution packages of ZTK are in .tar.gz format. But there are few exceptions. For consistency, can we use .tar.gz format for all releases ? Which are the exceptions? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Compression format for ZTK packages
On Wed, Dec 16, 2009 at 08:35, Baiju M mba...@zeomega.com wrote: Hi, Most of the source distribution packages of ZTK are in .tar.gz format. But there are few exceptions. For consistency, can we use .tar.gz format for all releases ? Why do we need consistency? I mostly use tgz, but that's only because I forget that I should use zip. :) -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Compression format for ZTK packages
Hello Martijn, I guess which were created by windowze people. It does zips by default. Wednesday, December 16, 2009, 3:39:00 PM, you wrote: MF Hi there, MF Baiju M wrote: Most of the source distribution packages of ZTK are in .tar.gz format. But there are few exceptions. For consistency, can we use .tar.gz format for all releases ? MF Which are the exceptions? MF Regards, MF Martijn MF ___ MF Zope-Dev maillist - Zope-Dev@zope.org MF https://mail.zope.org/mailman/listinfo/zope-dev MF ** No cross posts or HTML encoding! ** MF (Related lists - MF https://mail.zope.org/mailman/listinfo/zope-announce MF https://mail.zope.org/mailman/listinfo/zope ) -- Best regards, Adam GROSZERmailto:agros...@gmail.com -- Quote of the day: Faith affirms what the senses do not affirm, but not the contrary of what they perceive. It is above and not contrary to. - Blaise Pascal ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Compression format for ZTK packages
On Wed, Dec 16, 2009 at 4:40 PM, Adam GROSZER agros...@gmail.com wrote: I guess which were created by windowze people. It does zips by default. Nope. I only create zips being on Mac OS. With the tarfile module in Python 2.4 being utterly broken, I ran into too much trouble with broken tar.gzips over time. At least in the Plone world we demanded everyone to use zip files all the time as the sdist format. We haven't enforced that, though. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Compression format for ZTK packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 schrieb Hanno Schlichting: On Wed, Dec 16, 2009 at 4:40 PM, Adam GROSZER agros...@gmail.com wrote: I guess which were created by windowze people. It does zips by default. Nope. I only create zips being on Mac OS. With the tarfile module in Python 2.4 being utterly broken, I ran into too much trouble with broken tar.gzips over time. At least in the Plone world we demanded everyone to use zip files all the time as the sdist format. We haven't enforced that, though. +0.5 At least I would disallow .bz2 since most people don't have a Python interpreter with bz2 module installed. Andreas - -- ZOPYX Ltd. Co KG \ zopyx group Charlottenstr. 37/1 \ The full-service network for your D-72070 Tübingen \ Python, Zope and Plone projects www.zopyx.com, i...@zopyx.com \ www.zopyxgroup.com - E-Publishing, Python, Zope Plone development, Consulting -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkspAUkACgkQCJIWIbr9KYyMcwCfZ9+DHuqTkpCTJEewrCeTCZVr +UkAn3Eyf4bW+qXwg8XVOJ3a4dalXG3h =XtMT -END PGP SIGNATURE- attachment: lists.vcf___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Compression format for ZTK packages
On Wed, Dec 16, 2009 at 8:09 PM, Martijn Faassen faas...@startifact.com wrote: Hi there, Baiju M wrote: Most of the source distribution packages of ZTK are in .tar.gz format. But there are few exceptions. For consistency, can we use .tar.gz format for all releases ? Which are the exceptions? I just checked the included ZTK packages, here is the list: zope.container-3.9.1.zip zope.container-3.10.0.zip zope.contenttype-3.4.2.zip zope.copypastemove-3.4.1.zip zope.dublincore-3.4.1.zip zope.error-3.5.0.zip zope.formlib-3.5.0.zip zope.formlib-3.5.2.zip zope.html-2.0.0.zip zope.html-1.2.0.zip zope.i18n-3.7.1.zip zope.i18n-3.6.0.zip zope.i18nmessageid-3.4.2.zip zope.interface-3.5.0.zip zope.keyreference-3.6.2.zip zope.proxy-3.4.0.zip zope.proxy-3.4.1.zip zope.proxy-3.4.2.zip zope.publisher-3.3.3.zip zope.publisher-3.6.0.zip zope.publisher-3.6.1.zip zope.publisher-3.6.4.zip zope.publisher-3.11.0.zip zope.ramcache-1.0.zip zope.security-3.5.2.zip zope.security-3.4.1.zip zope.sendmail-3.5.1.zip zope.server-3.6.0.zip zope.session-3.9.1.zip zope.site-3.8.0.zip zope.tal-3.5.2.zip zope.testbrowser-3.7.0a1.zip zope.testing-3.8.2.zip zope.traversing-3.7.2.zip zope.traversing-3.5.3.zip zope.traversing-3.10.0.zip zope.traversing-3.9.0.zip zope.viewlet-3.5.0.zip zope.viewlet-3.6.1.zip Regards, Baiju M ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interfaces vs ZCA concepts
Martijn Faassen wrote: Thomas Lotze wrote: Martijn Faassen wrote: * have dummy implementations in zope.interface that raise NotImplementedError That would still introduce too many zope.component concepts into zope.interface IMO: obviously that of utilities as one of the dummy methods would bear that name, and those of named components and lookup contexts if the methods were to be specified by IInterface. I think having these markers is very important for code readability. People reading the code will otherwise have no idea whatsoever where these methods come from. I see your point, but I have two objections: - The very concept of the ZCA introduces a related problem with code readability: just by reading the code that uses components you will never be able to tell where a particular adapter or utility comes from, or even what adapters or utilities you can hope to look up in the first place. So having to have some knowledge of the larger system that uses the interface mechanics isn't an entirely new thing, and having to learn about these two methods is a very small one-time effort compared to the readability obstacles that using the system thus entails. - As pointed out before, I consider it a goal to treat all uses of interfaces equally (which seems to me to be related to the effort to make interfaces more of a part of the language). By implementing stubs for `adapt` and `utility` (or specifying them in IInterface) we'd make the ZCA stand out as a particular use of interfaces. IMO, we serve those who seek to understand the API just as well by documenting the two methods as prominent examples of interface usage. I guess we should make a decision about the latter point of view before discussing a particular implementation strategy. I'm not sure whether much of a general mechanism is really needed, after all we already have monkey patching (um, sorry Tres, modifying a class). I can see there being an API in zope.interface that allows one to plug into .utility() and .adapt() If you're talking about the component hooks, then that's the part I hope to get rid of as it causes more trouble than it helps. (This is what I tried to point out in the message that started this thread.) parameter isn't even called 'default' but 'alternate' in Interface.__call__. The very name of the default argument is another thing that is sneaking from zope.component into zope.component. Let's deprecate 'alternate' and introduce 'default' then. Might actually make the deprecation more easy.. I don't think so. We're going to deprecate not spelling out the name of the parameter, so it won't matter which name not to spell out. OTOH, we'll additionally have to deprecate the name `alternate` where it is used. I'm not sure whether we should make the name of that parameter consistent between zope.component and zope.interface, or leave it alone in order not to pretend the relation between the different implementations of adaptation to be stronger than it actually is. -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interfaces vs ZCA concepts
Thomas Lotze wrote: I'm not sure whether we should make the name of that parameter consistent between zope.component and zope.interface, Sorry, nevermind. Of course we'll want to rename that parameter as our secret plan is to access the ZCA through Interface.__call__ one day. -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Compression format for ZTK packages
On Wed, Dec 16, 2009 at 17:31, Baiju M mba...@zeomega.com wrote: Others has already raised their concern against .tar.gz as it is not working in Python 2.4 And bz2 module might be missing for many Python installations. (BTW, We don't have any bz2 source packages released) Right. So for consistency we should use zip. Then again, I'm don't see why we would want to be consistent. :) -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interfaces vs ZCA concepts
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Tres Seaver wrote:
Martin Aspeli wrote:
zope.component raises TypeError if you can't adapt. It raises
ComponentLookupError it can't find a utility.
Not so: see $ZSVN/zope.component/trunk/src/zope/component/registry.py:
I'm pretty sure you get a TypeError when Zope can't adapt. I'm not sure
where it's thrown from, though.
Stupid example:
from plone.portlets.interfaces import IPortletType
class X(object): pass
...
x = ()
IPortletType(x)
Traceback (most recent call last):
File console, line 1, in module
TypeError: ('Could not adapt', (), InterfaceClass
plone.portlets.interfaces.IPortletType)
The Could not adapt traceback tells you that it isnt The ZCA doing
that: it is the C code inside zope.interface. One might argue that a
better exception would be LookupError: we haven't violted the
contract here.
class Components:
...
def getUtility(self, provided, name=u''):
utility = self.utilities.lookup((), provided, name)
if utility is None:
raise ComponentLookupError(provided, name)
return utility
...
def getAdapter(self, object, interface, name=u''):
adapter = self.adapters.queryAdapter(object, interface, name)
if adapter is None:
raise ComponentLookupError(object, interface, name)
return adapter
getAdapter() is different, though:
from zope.component import getAdapter
getAdapter(x, IPortletType)
Traceback (most recent call last):
File console, line 1, in module
File
/Users/optilude/.buildout/eggs/zope.component-3.7.1-py2.6.egg/zope/component/_api.py,
line 98, in getAdapter
raise ComponentLookupError(object, interface, name)
ComponentLookupError: ((), InterfaceClass
plone.portlets.interfaces.IPortletType, u'')
which matches the contract spelled out in the docstrings for IComponent.
That class raises TypeError only for invalid values passed to the
various registration functions.
Something else is raising TypeError then. :)
The interface machinery catches whatever the adapter hook raises and
returns a TypeError instead.
At any rate, we are talking about errors raised from zope.itnerface
APIs, which nowhere mention or use CLE::
Ok.
$ svn info . | grep URL
URL: svn+ssh://svn.zope.org/repos/main/zope.interface/trunk
$ svn up
At revision 106615.
$ find . -name *.py | xargs grep ComponentLookupError
$
Nobody calling an interface today has any *defined* behavior to expect
in the case of failure (in fact, '__call__' is not even part of IInterface!)
Please point to existing code which calls 'IFoo.utility(name=bar)' and
catches a CLE. Since this is a new API we are talkign about, there
can't be any BBB concerns.
True, but we're also going to ask people to change their use of
getUtility(IFoo) to IFoo.utility and ditto for adaption. If I have
existing code that looks like this:
try:
foo = IFoo(bar)
except TypeError:
pass
I would like to be able to move that mechanically to:
try:
foo = IFoo.adapt(bar)
except TypeError:
pass
I can't see anything compelling about making that transform mechanical.
As noted above, it is already *wrong* to be relying on a specific
exception type here anyway.
If I have to change the exception type in any of the scenarios (utility
lookup would be similar) then that would be another change to detect,
and possibly a harder one to spot in less contrived code.
Any code today which wants a utility is calling 'getUtilty' (if it
*knows* the utility must be registered) or 'queryUtility' (if it thinks
it might not be). Less facetiously than my first challenge: please
point to actual code in the wild which looks like::
try:
foo = getUtilty(IFoo, name='bar')
except ComponentLookupError:
# do something
instead of::
foo = queryUtility(IFoo, name='bar')
if foo is None:
# do something
I will argue that any code doing the first, outside of maybe tests of
the ZCA itself is plain broken.
Perhaps, but I'm pretty sure people have done this. They may also have
done it in tests.
Why would we bend over backward to keep obviously broken code seeming to
work?
I'm not religious about it, but I think that if we're only changing the
API, it'd be preferable not to change the exceptions we throw unless
semantics also change.
Given that the behavior isn't part of any API to date, I'm suggesting
that we *document* the behavior ahead of time (for new code), without
any regard for BBB. We could document the existing __call__ behavior as
well, if needed.
In either case, I think TypeError (or maybe LookupError) is the *right*
choice: we don't want to hide zope.component's API functions and then
turn around and require folks to import zope.component just to catch its
local exception types.
Re: [Zope-dev] Interfaces vs ZCA concepts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Thomas Lotze wrote: Martijn Faassen wrote: * have dummy implementations in zope.interface that raise NotImplementedError That would still introduce too many zope.component concepts into zope.interface IMO: obviously that of utilities as one of the dummy methods would bear that name, and those of named components and lookup contexts if the methods were to be specified by IInterface. I think having these markers is very important for code readability. People reading the code will otherwise have no idea whatsoever where these methods come from. I'm not sure whether much of a general mechanism is really needed, after all we already have monkey patching (um, sorry Tres, modifying a class). I can see there being an API in zope.interface that allows one to plug into .utility() and .adapt() I don't see any win for the generic extensions either: we already know *exactly* what two methods we want to use, and have no use cases at all for adding any others. * have that NotImplementedError say to look for implementations in zope.component I would actually like a mechanism that doesn't care about what package will inject which pieces of API. Do you think such generality is asking too much (at least at this point in time)? I think it will be less clear compared to the methods being there and saying they're injection points intended to be overwritten. - -1 to any docstring / exception method which points outside the zope.itnerface package. There is a perfectly reasonable default implementation anyway (in the absence of any hooks): - - IFoo.adapt(context) raises LookupError, unless the context provides IFoo, in which case it returns context. - - IFoo.adapt(context, default=default) returns default unless context provides IFoo, in which case it returns context. - - IFoo.utility() raises LookupError. - - IFoo.utility(default=default) returns default I would much rather keep a hook registration API in the interface class for these methods than obscure their origin semantics via a monkey patch. Did you make an implicit 'default' deprecated on __call__ yet by the way? Not yet; the other issue looked more interesting so far ;o) BTW, that parameter isn't even called 'default' but 'alternate' in Interface.__call__. The very name of the default argument is another thing that is sneaking from zope.component into zope.component. Let's deprecate 'alternate' and introduce 'default' then. Might actually make the deprecation more easy.. Note that Interface.__call__ is not documented at all as an API:: $ grep __call__ src/zope/interface/interfaces.py $ I think we should just rename the argument without any deprecation. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkspVZYACgkQ+gerLs4ltQ52fACcC3Pd8uGvTzjkKwmTX97PrQaf oxkAoLoA1lRxpPA6HpQYQtifxQBM8sbF =jebA -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Compression format for ZTK packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: On 2009-12-16 08:35, Baiju M wrote: Hi, Most of the source distribution packages of ZTK are in .tar.gz format. But there are few exceptions. For consistency, can we use .tar.gz format for all releases ? Once there is a python 2.4 release which fixes the tarfile bug, That release is scheduled for February 31st next year. :) or once python 2.4 support is officially no longer desirable. In practice, the tarfile bug only affects a very small percentage of packages (they need to contain a file member with a '/' character in the 100th position in its name). Anybody who builds a package which generates such a name will just (eventually, anyway) figure out to use zipfile: for everybody else, the distinction is meaningless. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkspVvUACgkQ+gerLs4ltQ77egCfWaAre4U2rDJGtik2PcdSn34k ER8AniYMarNcjsKoKeK2nEYRPM0zofdK =WRT/ -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Compression format for ZTK packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baiju M wrote: On Wed, Dec 16, 2009 at 9:23 PM, Chris Withers ch...@simplistix.co.uk wrote: Baiju M wrote: Most of the source distribution packages of ZTK are in .tar.gz format. But there are few exceptions. For consistency, can we use .tar.gz format for all releases ? Why does anyone care? They both work the same on all platforms... Others has already raised their concern against .tar.gz as it is not working in Python 2.4 It doesn't affect the huge majority of pacakges we produce. For any package it does affect, we use zip, sure. And bz2 module might be missing for many Python installations. (BTW, We don't have any bz2 source packages released) That still doesn't require consitency: we just need to test that the packages we make can be installed on all supported platforms. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkspV2UACgkQ+gerLs4ltQ5+hwCgn5ABDO3+M8jL3NJO5VA8Zw1Z gKYAn0nlRUWoAvtf4xum0jpTFRtvKPII =623s -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interfaces vs ZCA concepts
Tres Seaver wrote: In either case, I think TypeError (or maybe LookupError) is the *right* choice: we don't want to hide zope.component's API functions and then turn around and require folks to import zope.component just to catch its local exception types. Yeah, that's a compelling reason. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interfaces vs ZCA concepts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Tres Seaver wrote: In either case, I think TypeError (or maybe LookupError) is the *right* choice: we don't want to hide zope.component's API functions and then turn around and require folks to import zope.component just to catch its local exception types. Yeah, that's a compelling reason. I have checked in a branch which makes failed adaptation (inside the __call__ of an interface) raise a LookupError instead of a TypeError: the branch also documents the semantics of __call__. I would like to merge this to the trunk a 3.6.0 version (bumped to indicate the quasi-API change). http://svn.zope.org/zope.interface/branches/tseaver-raise_lookup_error/?rev=106688view=rev Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkspjwMACgkQ+gerLs4ltQ4mggCg090UYuKxFt2WH5iuiQJvqtbT yMwAoNPvKEhj2xKhWiribWNT+j7/LBUa =k4US -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] 64bit Windows binaries
Hi, Any plan for releasing 64 bit Windows binaries for ZODB, ZTK Zope 2 ? Anyone used MinGW for 64 bit Windows to compile Zope packages ? Regards, Baiju M ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope] question about copyng btree elements
Hi! I've a Zope BTree called answers. It contains PersistentMapping objects: self.answers[userid] = PersistentMapping(value=value, comments=comments) value can be a string, a list or a dictionary what happen exactly if I do: question.answers[a_userdid] = question.answers[another_user_id] ? From my (poor) tests they seems not to share anything, I mean I can modify question.answers[a_userdid] and question.answers[another_user_id] is untouched. Is this true? Should I beware of something? ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] question about copyng btree elements
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yuri wrote:
Hi!
I've a Zope BTree called answers. It contains PersistentMapping objects:
self.answers[userid] = PersistentMapping(value=value,
comments=comments)
value can be a string, a list or a dictionary
what happen exactly if I do: question.answers[a_userdid] =
question.answers[another_user_id] ?
From my (poor) tests they seems not to share anything, I mean I can
modify question.answers[a_userdid] and question.answers[another_user_id]
is untouched.
Is this true? Should I beware of something?
I can't reproduce your reported behavior::
- - $ --
$ bin/virtualenv-2.6 --no-site-packages /tmp/yuri
...
$ cd /tmp/yuri/
$ bin/easy_install ZODB3
...
$ bin/python
...
from BTrees.OOBTree import OOBTree
from persistent.mapping import PersistentMapping
answers = OOBTree()
john = PersistentMapping(value=John's value,
... comment=John's comment)
answers['john'] = john
answers['fred'] = answers['john']
answers['fred'] is john
True
print john
{'comment': John's comment, 'value': John's value}
answers['fred']['value'] = Fred's value
print john
{'comment': John's comment, 'value': Fred's value}
- - $ --
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkspT6MACgkQ+gerLs4ltQ78PgCfRQMXXXDUOSSuViYtBW18muM7
oVYAoK5iL9klE15WBhjvte8KjNNNUUKt
=br64
-END PGP SIGNATURE-
___
Zope maillist - Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope-dev )
