[Zope-CMF] CMF Collector: Open Issues
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open mhammond - "Windows DevelopmentMode penalty in CMFCore.DirectoryView", [Accepted] http://www.zope.org/Collectors/CMF/366 Pending / Deferred Issues - "FSPropertiesObject.py cannot handle multiline input for lines, text attributes", [Deferred] http://www.zope.org/Collectors/CMF/271 - "Can't invalidate skin items in a RAMCacheManager", [Pending] http://www.zope.org/Collectors/CMF/343 - "workflow notify success should be after reindex", [Deferred] http://www.zope.org/Collectors/CMF/389 - "Possible bug when using a BTreeFolder Member folder", [Pending] http://www.zope.org/Collectors/CMF/441 - "Proxy Roles not Working/Applied to Worflow Transition Scripts", [Pending] http://www.zope.org/Collectors/CMF/449 - "safe_html filters some tags which should probably not be filtered", [Pending] http://www.zope.org/Collectors/CMF/452 - "purge_old in runAllImportSteps not working", [Pending] http://www.zope.org/Collectors/CMF/455 - "Danger from Caching Policy Manager", [Pending] http://www.zope.org/Collectors/CMF/460 - "properties setup handler: support for non-ascii strings", [Pending] http://www.zope.org/Collectors/CMF/468 - "GenericSetup does not handle non-ascii data well", [Pending] http://www.zope.org/Collectors/CMF/471 - "autocreation of catalog indexes", [Pending] http://www.zope.org/Collectors/CMF/472 - "[GS] Error when choosing initial_configuration ", [Pending] http://www.zope.org/Collectors/CMF/473 Pending / Deferred Features - "Favorite.py: queries and anchors in remote_url", [Pending] http://www.zope.org/Collectors/CMF/26 - "DefaultDublinCore should have Creator property", [Pending] http://www.zope.org/Collectors/CMF/61 - "Document.py: universal newlines", [Pending] http://www.zope.org/Collectors/CMF/174 - "portal_type is undefined in initialization code", [Pending] http://www.zope.org/Collectors/CMF/248 - "CMFTopic Does Not Cache", [Deferred] http://www.zope.org/Collectors/CMF/295 - "Wishlist: a flag that tags the selected action.", [Pending] http://www.zope.org/Collectors/CMF/301 - "CMFDefault should make use of allowCreate()", [Pending] http://www.zope.org/Collectors/CMF/340 - "Nested Skins", [Deferred] http://www.zope.org/Collectors/CMF/377 - "CatalogVariableProvider code + tests", [Pending] http://www.zope.org/Collectors/CMF/378 - "manage_doCustomize() : minor additions", [Pending] http://www.zope.org/Collectors/CMF/382 - "CMF needs View-based TypeInformation", [Pending] http://www.zope.org/Collectors/CMF/437 - "Marker attributes should be deprecated", [Pending] http://www.zope.org/Collectors/CMF/440 - "New getNextEvent Method", [Pending] http://www.zope.org/Collectors/CMF/462 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: getToolByName depreciation, getUtility, and five.lsm
Hi, I'll just offer one alternative solution for disussion, which could avoid reverting all the changes we made. Kapil Thangavelu wrote: > We believe that these recent changes have introduced implicit magic into > a standard Zope3 api to fit Zope2 acquisition. There should be an > explicit separate api if we want acquisition wrapped context-aware > utilities. As an example of a symptom caused by the implicit > implementation, KSS (which was developed as a pure zope 3 component) > breaks when used with Plone, even though it is a perfectly valid z3 > component. Once we return to using getToolByName for tool lookup, the > KSS/Plone3 issue disappears, because the magic wrapping of things stops. > This KSS/Plone3 issue arises because the five.lsm acquisition breaks > down when you add in non five.lsm component registries. If you need > Zope2 acquisition, you should use an accessor api to get things wrapped. I would say that all of Acquisition is dark implicit magic and something I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2 I also expect the need to make the Zope 3 code Acquisition aware. One prime example are browser views, which I need to mix in Acquisition in order for them to work. From my perspective the same could apply to site managers / component registries. As we already need to make a specialized subclass for local site managers to make them work in Zope 2 I think it would be another possibility to enforce the same for non-persistent site managers. This could lead us to a second package five.sitemanager that is aware of the same kind of Acquistion wrapping that five.lsm implies right now. The monkey patches we need right now could go away and KSS could do a conditional import of the site manager from zope.component or five.sitemanager if it is found. > In addition, getToolByName is the most fundamental and widely used api > in all of CMF, and we're going to be issuing hundreds of deprecating > warnings for every single cmf application extant. Yes, and I think in order to move forward and someday be able to remove tools from content space, not to mention not to enforce beginners to learn about yet another CMF-ism named tools, we need to be prepared to make some more intrusive changes sometimes. > As a solution, we propose > > * The five.localsitemanager code should *NOT* be dealing with > acquisition, it should be restricted to setting up a bases chain for > persistent components that does parent lookup. > > * getToolByName deprecation should be reverted. Its internal mechanisms > should be kept the same as in the current CMF 2.1 release, using > getUtility, *AND* it should be the one doing acquisition wrapping. > > So instead of doing implicit magic in the getUtility call stack, let's > be explicit, while still allowing the flexibility that registered > components provide. Which in turn results in an untouched zope3 > getUtility execution path for looking up utilities. > > getToolByName should return acquisition wrapped utilities via name > mapping, and become un-deprecated. Context for wrapping would be the > context passed as an argument to getToolByName, as it always has been. > It would issue deprecation warnings when it has to lookup a tool via > aq_get instead of getUtility. The mechanism for registering tool names > would raise an error when anyone tries to register a component which > does not support Acquisition. > > The getToolByInterfaceName method would no longer be necessary as > getToolByName can be called from restricted code. However if needed it > could remain and use the result of getSite() as the context for wrapping > the tool resulting from the utility lookup. In my alternative we would just need to add a little new package which is mostly a copy/paste job, change KSS to do an conditional import (so it still works in pure Zope 3) and document the change. Looking at Zope 2.11 we will potentially get Acquisition through __parent__ pointers which would allow us to make the implementation of five.sitemanger a lot saner and ultimately allow us to remove it again altogether. > We don't mean to belittle the hard work that anyone has put into this so > far, and we hope this is received in the spirit that it is intended. We > are willing to implement this if we can reach some consensus that this > is the right thing to do. All I'm interested in is a proper solution. Should that imply reverting lots of things I have done it would be unfortunate but obviously the right thing to do :) Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF Tests: 9 Failed, 2 Unknown
Stefan H. Holek, on 2007-03-28:
> Much fun to be had with daylight-saving, eh?
>
> FWIW, I have double-checked the system time, timezone, and locale
> settings on the machine running the nightlies, and everything appears
> to be sane. I see the same failure on my Mac, so /me shrugs...
I am in the Netherlands, which is GMT+1, though with the dst it would
be GMT+2. I see this:
>>> from DateTime import DateTime
>>> DateTime(0)
DateTime('1970/01/01 01:00:00 GMT+1')
I see the same problem in a Plone Product of mine (eXtremeManagement)
where bookings added after the DST get listed a day earlier in one
page template. When I add a booking somewhere in November (I can
choose the booking date) that one gets listed fine again.
I am wondering what should be done. I *think* I can fix my own Python
Script that is responsible for this now I know that DST is involved.
I want to move to a browser view anyway.
But does this point to a deeper problem? Does something need to be
fixed in CMF or Zope?
In other words: does this just go wrong in a few isolated places that
need to be fixed individually or does this need a fix in one deeper
spot?
--
Maurits van Rees | http://maurits.vanrees.org/ [NL]
Work | http://zestsoftware.nl/
"Do not worry about your difficulties in computers,
I can assure you mine are still greater."
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF Tests: 9 Failed, 2 Unknown
Maurits van Rees, on 2007-03-29: > I see the same problem in a Plone Product of mine (eXtremeManagement) > where bookings added after the DST get listed a day earlier in one > page template. When I add a booking somewhere in November (I can > choose the booking date) that one gets listed fine again. > > I am wondering what should be done. I *think* I can fix my own Python > Script that is responsible for this now I know that DST is involved. > I want to move to a browser view anyway. For the record: I just fixed it in my product. This is probably *very* specific to my product, but maybe it gives someone hints for the failing cmf tests. Here is the changeset: http://dev.plone.org/collective/changeset/39931/eXtremeManagement I was iterating through all days of the month, doing date+1 to go to the next day. That is apparently not the right thing to do in a DST context. I now fixed this by incrementing the day count and constructing a new DateTime object with date = DateTime(year, month, day). -- Maurits van Rees | http://maurits.vanrees.org/ [NL] Work | http://zestsoftware.nl/ "Do not worry about your difficulties in computers, I can assure you mine are still greater." ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: getToolByName depreciation, getUtility, and five.lsm
Hanno Schlichting wrote: I would say that all of Acquisition is dark implicit magic and something I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2 I also expect the need to make the Zope 3 code Acquisition aware. One prime example are browser views, which I need to mix in Acquisition in order for them to work. But Products.Five.BrowserView hides that particular detail from you, as much as getToolByName could hide the acquisition detail when looking up tools. You're suggesting to introduce yet another package that's destined to go a way at some point, while the same functionality is already available, it only needs to be un-deprecated... -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF Tests: 9 Failed, 2 Unknown
Maurits van Rees wrote: Maurits van Rees, on 2007-03-29: I see the same problem in a Plone Product of mine (eXtremeManagement) where bookings added after the DST get listed a day earlier in one page template. When I add a booking somewhere in November (I can choose the booking date) that one gets listed fine again. I am wondering what should be done. I *think* I can fix my own Python Script that is responsible for this now I know that DST is involved. I want to move to a browser view anyway. For the record: I just fixed it in my product. This is probably *very* specific to my product, but maybe it gives someone hints for the failing cmf tests. Here is the changeset: http://dev.plone.org/collective/changeset/39931/eXtremeManagement I was iterating through all days of the month, doing date+1 to go to the next day. That is apparently not the right thing to do in a DST context. I believe date+1 will simply add 24*60*60 seconds, hence the offset when adding over the DST switch. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] CMF Tests: 9 Failed, 2 Unknown
Summary of messages to the cmf-tests list. Period Wed Mar 28 12:00:00 2007 UTC to Thu Mar 29 12:00:00 2007 UTC. There were 11 messages: 11 from CMF Unit Tests. Test failures - Subject: FAILED (failures=1) : CMF-1.5 Zope-2.7 Python-2.3.6 : Linux From: CMF Unit Tests Date: Wed Mar 28 21:24:38 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004476.html Subject: FAILED (failures=1) : CMF-1.5 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Wed Mar 28 21:26:08 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004477.html Subject: FAILED (failures=1) : CMF-1.5 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Mar 28 21:27:38 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004478.html Subject: FAILED (failures=1) : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Wed Mar 28 21:29:08 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004479.html Subject: FAILED (failures=1) : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Mar 28 21:30:38 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004480.html Subject: FAILED (failures=1) : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Mar 28 21:32:08 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004481.html Subject: FAILED (failures=1) : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Mar 28 21:33:38 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004482.html Subject: FAILED (failures=1) : CMF-2.1 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Mar 28 21:35:08 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004483.html Subject: FAILED (failures=1) : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Mar 28 21:38:08 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004485.html Unknown --- Subject: UNKNOWN : CMF-2.1 Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Mar 28 21:36:38 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004484.html Subject: UNKNOWN : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Mar 28 21:39:39 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004486.html ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF Tests: 9 Failed, 2 Unknown
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Maurits van Rees wrote:
> Stefan H. Holek, on 2007-03-28:
>> Much fun to be had with daylight-saving, eh?
>>
>> FWIW, I have double-checked the system time, timezone, and locale
>> settings on the machine running the nightlies, and everything appears
>> to be sane. I see the same failure on my Mac, so /me shrugs...
>
> I am in the Netherlands, which is GMT+1, though with the dst it would
> be GMT+2. I see this:
>
from DateTime import DateTime
DateTime(0)
> DateTime('1970/01/01 01:00:00 GMT+1')
>
> I see the same problem in a Plone Product of mine (eXtremeManagement)
> where bookings added after the DST get listed a day earlier in one
> page template. When I add a booking somewhere in November (I can
> choose the booking date) that one gets listed fine again.
>
> I am wondering what should be done. I *think* I can fix my own Python
> Script that is responsible for this now I know that DST is involved.
> I want to move to a browser view anyway.
>
> But does this point to a deeper problem? Does something need to be
> fixed in CMF or Zope?
>
> In other words: does this just go wrong in a few isolated places that
> need to be fixed individually or does this need a fix in one deeper
> spot?
I think there may be a related error in Zope's DataTime package:
http://www.zope.org/Collectors/Zope/2290
The consensus is that the Right Thing(TM) is to switch over to using
pytz, which is updated regularly when the politically-defined DST rules
change; I'm not sure anyone has worked out how to do this, however.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGC9MW+gerLs4ltQ4RAm96AJ9wthVuemzKMSF9Zorir/Y/xVtkPQCeOZ9C
Sa5UbjQoHIFVYTGrNvADXQE=
=CMcO
-END PGP SIGNATURE-
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: getToolByName depreciation, getUtility, and five.lsm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > Hanno Schlichting wrote: >> I would say that all of Acquisition is dark implicit magic and something >> I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2 >> I also expect the need to make the Zope 3 code Acquisition aware. One >> prime example are browser views, which I need to mix in Acquisition in >> order for them to work. > > But Products.Five.BrowserView hides that particular detail from you, as > much as getToolByName could hide the acquisition detail when looking up > tools. > > You're suggesting to introduce yet another package that's destined to go > a way at some point, while the same functionality is already available, > it only needs to be un-deprecated... +1 for removing the "across-the-board" deprecation of 'getToolByName'; I find Kapil's argument convincing here. I think leaving the deprecation for the case where the API has to fall back to raw acquisition to find the tool is pretty reasonable, as it shows the user where the missing registrations are in her site. I'm not sure what impact that would have for the already-converted code which used to use the API. I can see value both in leaving it converted, as showing the Zope3-ish way, as well as in reverting some or all of it. For instance, perhaps we should consider reverting just those changes which look up acquisition-dependent tools, since the call site has now become required to manage the wrapper itself. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGC9TO+gerLs4ltQ4RAjNNAJ9UsTpKulDZqns+yrjyDHuslsqaqACfR8El RcwOrIOhyedU+O90JjOgl84= =bCSl -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] getToolByName depreciation, getUtility, and five.lsm
Tres Seaver wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Philipp von Weitershausen wrote: >> Hanno Schlichting wrote: >>> I would say that all of Acquisition is dark implicit magic and something >>> I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2 >>> I also expect the need to make the Zope 3 code Acquisition aware. One >>> prime example are browser views, which I need to mix in Acquisition in >>> order for them to work. >> >> But Products.Five.BrowserView hides that particular detail from you, as >> much as getToolByName could hide the acquisition detail when looking up >> tools. >> >> You're suggesting to introduce yet another package that's destined to go >> a way at some point, while the same functionality is already available, >> it only needs to be un-deprecated... > > +1 for removing the "across-the-board" deprecation of 'getToolByName'; > I find Kapil's argument convincing here. I think leaving the > deprecation for the case where the API has to fall back to raw > acquisition to find the tool is pretty reasonable, as it shows the user > where the missing registrations are in her site. > > I'm not sure what impact that would have for the already-converted code > which used to use the API. I can see value both in leaving it > converted, as showing the Zope3-ish way, as well as in reverting some or > all of it. For instance, perhaps we should consider reverting just > those changes which look up acquisition-dependent tools, since the call > site has now become required to manage the wrapper itself. > Do we have any idea *which* tools are "acquisition-dependent" and which ones are not? By this, I mean which tools expect to be able to acquire things from 'self', for example, not so much acquisition-dependent security around tools being accessed TTW. Martin -- View this message in context: http://www.nabble.com/getToolByName-depreciation%2C-getUtility%2C-and-five.lsm-tf3483581.html#a9735489 Sent from the Zope - CMF list2 mailing list archive at Nabble.com. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CMF Tests: 9 Failed, 2 Unknown
On 3/29/07, Tres Seaver <[EMAIL PROTECTED]> wrote: The consensus is that the Right Thing(TM) is to switch over to using pytz, which is updated regularly when the politically-defined DST rules change; I'm not sure anyone has worked out how to do this, however. But that also means pytz has to be kept up-to-date. I haven't seen any checkin updating pytz in the last month(s). -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: getToolByName depreciation, getUtility, and five.lsm
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Hanno Schlichting wrote: I would say that all of Acquisition is dark implicit magic and something I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2 I also expect the need to make the Zope 3 code Acquisition aware. One prime example are browser views, which I need to mix in Acquisition in order for them to work. and if understand correctly, this is an artefact of views needing to abide by traversal and security. Any tool that does not expressly need security can probably do without acquisition(unless it has code depending on using aquisition for look ups). But Products.Five.BrowserView hides that particular detail from you, as much as getToolByName could hide the acquisition detail when looking up tools. You're suggesting to introduce yet another package that's destined to go a way at some point, while the same functionality is already available, it only needs to be un-deprecated... +1 for removing the "across-the-board" deprecation of 'getToolByName'; I find Kapil's argument convincing here. I think leaving the deprecation for the case where the API has to fall back to raw acquisition to find the tool is pretty reasonable, as it shows the user where the missing registrations are in her site. I'm not sure what impact that would have for the already-converted code which used to use the API. I can see value both in leaving it converted, as showing the Zope3-ish way, as well as in reverting some or all of it. For instance, perhaps we should consider reverting just those changes which look up acquisition-dependent tools, since the call site has now become required to manage the wrapper itself. +1 to undeprecating and slimming lsm. but to echo tres, only the roll back the calls you really have to. -w -- -- d. whit morriss -- - senior engineer, opencore - - http://www.openplans.org - - m: 415-710-8975 - "If you don't know where you are, you don't know anything at all" Dr. Edgar Spencer, Ph.D., 1995 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF Tests: 9 Failed, 2 Unknown
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sidnei da Silva wrote: > On 3/29/07, Tres Seaver <[EMAIL PROTECTED]> wrote: >> The consensus is that the Right Thing(TM) is to switch over to using >> pytz, which is updated regularly when the politically-defined DST rules >> change; I'm not sure anyone has worked out how to do this, however. > > But that also means pytz has to be kept up-to-date. I haven't seen any > checkin updating pytz in the last month(s). The cheeseshop shows a pytz-2007d version: http://cheeseshop.python.org/pypi/pytz Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGC/cr+gerLs4ltQ4RAln/AJ0bVoqvyu7Y7JuyEArI5eKhUCkNCQCg08Fm v2Kh5b0j19HBdSkYVEie1FU= =xeAd -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CMF Tests: 9 Failed, 2 Unknown
On 3/29/07, Tres Seaver <[EMAIL PROTECTED]> wrote: The cheeseshop shows a pytz-2007d version: http://cheeseshop.python.org/pypi/pytz I was refering to the version included in Zope. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF Tests: 9 Failed, 2 Unknown
Sidnei da Silva wrote: On 3/29/07, Tres Seaver <[EMAIL PROTECTED]> wrote: The cheeseshop shows a pytz-2007d version: http://cheeseshop.python.org/pypi/pytz I was refering to the version included in Zope. That's because we're using a stupid vendor import instead of simply requiring it as an install (same with docutils, btw... at least with twisted we use an external). There are two pytz-related bugs in the Zope 3 bugtracker: - https://bugs.launchpad.net/zope3/+bug/98494 - https://bugs.launchpad.net/zope3/+bug/98495 which were both suspiciously filed on March 13th this year, therefore shortly after the new DST change date. The latter one is about updating pytz... When Zope 3 becomes eggs (we're almost there now), I really really hope we can simply depend on 3rd party packages as eggs... -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: getToolByName depreciation, getUtility, and five.lsm
Tres Seaver wrote: I'm not sure what impact that would have for the already-converted code which used to use the API. I can see value both in leaving it converted, as showing the Zope3-ish way, as well as in reverting some or all of it. For instance, perhaps we should consider reverting just those changes which look up acquisition-dependent tools, since the call site has now become required to manage the wrapper itself. I would only be comfortable doing that if we had unit tests for those tools that aren't acquisition-dependent. And by unit test, I mean real unit tests and not a ZopeTestCase. That's the only way we can really be sure that that a tool can function as a utility, an independent component, w/o acquisition. Not knowing the codebase, I suspect that this isn't the case and suggest using getToolByName for all right now and adding such tests to the TODO list for the next CMF release. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Delete trouble
Philipp von Weitershausen wrote at 2007-3-28 08:16 +0200: > ... >What makes you think you can make that assumption? This is Zope 2 all >over again, where things just have to be there. That won't help >making things more flexible. Hiding exceptions (or avoiding them at all costs) might be seen as more flexible -- but this approach caused several quality problems in Zope 2. >> We have this situation here: there should be (and is) a unique >> id tool but the local registrations have not been performed. > >Nope, we're just not operating in a place where we can get to the >tool. It's standard acquisition semantics. With standard acquisition semantics, you get an AttributeError when the object is not there. You propose something similar (okay, a bit less drastic) to silently ignoring the "AttributeError". I argue that (in general, there are exceptions) we should get the exception. > >> An exception is better than silently omit the update of the existing >> unique id tool. >> You could argue that the local id tool does not need to be updated >> as the complete site (including the tool) gets deleted. > >Indeed. > >> But would the effect be different, if I used: >> >> plone_site.some_folder.manage_deleteObjects(). >> >> Or in other words, is attribute lookup entailed in traversal? > >No. > >> If it is not (which I assume), then your "defensive programming" >> would hide inconsistencies in the unique id tool -- similar >> to a "defensive try: except: pass". > >What kind of inconsistencies? We're deleting the thing anyway, what's >the point to update it? If you carefully look at the example, it no longer deletes "plone_side" (and its "unique id tool") but something below "plone_side". Therefore, consistency of the "unique_id_tool" may be an issue (it is not deleted and would know about an object with no longer exists). -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
