[Zope-dev] Style guide update?
At one point, we had a style guide that recommended simple "import " import statements for Zope code: http://wiki.zope.org/zope3/ZopePythonStyleGuide Today, I'm noticing a lot of commits with the change note "Normalize imports" that change all imports to "from import whatever", like this one: https://github.com/zopefoundation/zope.security/commit/115691fce9c80a340f271410eec2964c92fbace4 Do we still have an agreed-upon style guide, or are we moving to a last-touched-by approach? -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] [Checkins] SVN: zc.buildout/ Moved to github
On Sat, Aug 18, 2012 at 6:46 AM, Wichert Akkerman wrote: > Doesn't the name zc.buildout imply that it is a Zope Corp project instead of > a Zope Foundation one? The author has also never been listed as the > foundation but Jim personally, which seems to imply zc.buildout never was > Zope Foundation-owned software. Jim *wrote* the software (and is therefore the author, regardless of who *owns* it), and gave it to the Zope Foundation under his contributor's agreement. Therefore, the Foundation and Zope Corporation both have equal ownership stakes. -Fred -- Fred L. Drake, Jr. "A person who won't read has no advantage over one who can't read." --Samuel Langhorne Clemens ___ 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] RFC: drop interactive feature of zdaemon
On Tue, Jun 5, 2012 at 10:00 AM, Jim Fulton wrote: > I (and many people I know) find the interactive feature of > zdaemon annoying. I'd like to drop it, both to reduce annoyance > and to reduce the amount of code to maintain. I've never found this a useful feature. +1 -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] Content Type Meta tag stripping in zope.pagetemplate
On Tue, Mar 27, 2012 at 6:36 AM, Charlie Clark wrote: > True but I think that the problem was largely of our own making in not > coming up with "one, preferably only one" way of handling this. Re-reading > Marius' post I was struck by the whole idea of the http-server transcoding > the content on the fly. Transcoding on the fly? The page template generates Unicode; that's then encoded. Are you suggesting we shouldn't be using Unicode as the internal representation? Failure to do so would make it easy to get things wrong. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] Content Type Meta tag stripping in zope.pagetemplate
On Tue, Mar 27, 2012 at 4:54 AM, Charlie Clark wrote: > """ > We had bug reports about Web sites sending BOM different from the HTTP > header. > """ In other words... "the web" will continue to thrive on hacks and sniffing data to support users' expectations in spite of the data on "the web". I appreciate the motivation (it's not the users' fault the content provider can't get it right), it saddens me that there will no end of quirks-mode-like data interpretation. And that after this many years, we still can't get content-type and encodings straightened out. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] Content Type Meta tag stripping in zope.pagetemplate
On Thu, Feb 23, 2012 at 2:54 AM, Miano Njoka wrote: > Yes, this is true, but why strip out the meta tag from the resulting HTML? Two reasons: 1. It may be incorrect. 2. If multiple templates are used to construct a response, different values may be included from each template, which may be inconsistent. Since the meta element is unnecessary, it seemed better to leave it out of the result, and rely on other components to render the correct values without requiring them to insert correct values into the rendered template. (The publisher, for instance, shouldn't need to know how to edit that into the finished HTML.) -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] Content Type Meta tag stripping in zope.pagetemplate
On Wed, Feb 22, 2012 at 10:28 AM, Miano Njoka wrote: > /> tags were being stripped out from ZPT templates. Is there a reason > for this? As I recall, the rationale goes like this: 1. We're sniffing the input encoding from the charset setting. 2. We're storing the content-type on the instance (I hope tihs is still true). 3. The template/application/publisher is responsible for delivering the the output with an appropriate content-type header. -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] ZConfig: multi-line values
On Fri, Jan 6, 2012 at 2:33 AM, Chris Withers wrote: > if I implemented support for filters inside handler sections, would you > crank out a release? I'd definitely consider it. Someone made a mess of the ZConfig build (some silliness about using setup.py as a test driver), so you might need to look at that to make the buildout useful. -Fred -- Fred L. Drake, Jr. "A person who won't read has no advantage over one who can't read." --Samuel Langhorne Clemens ___ 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] ZConfig: multi-line values
On Thu, Jan 5, 2012 at 1:47 PM, Chris Withers wrote: > Is there any way in ZConfig to allow a file that looks like this: ... > ...or some other way of spelling multi-line values for a key? Nope, sorry. I played with adding that at one point, but didn't have enough time or motivation. There are a lot of limitations in the current syntax. -Fred -- Fred L. Drake, Jr. "A person who won't read has no advantage over one who can't read." --Samuel Langhorne Clemens ___ 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] Undelivered Mail Returned to Sender
On Wed, Nov 9, 2011 at 3:57 AM, Chris Withers wrote: > Is it Bejni's address, the email in question or that isn't coming from > server1.simplistix.co.uk? Benji's email address is benji at benjiyork.com. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] zc.async.queue.DispatcherAgents last_ping
On Wed, Jun 29, 2011 at 7:57 AM, Hanno Schlichting wrote: > Ideally I'd like to get avoid storing such information in the ZODB at > all and would much prefer a volatile attribute, a thread local or > something on the filesystem. But maybe I'm missing something here were > this information needs to be shared across workers running on > different machines. I do believe that's the case. Increasing the period is probably safe. Another strategy you can employ is to use a separate database for the zc.async bookkeeping; that could have different pack policies or a completely different storage implementation. -Fred -- Fred L. Drake, Jr. "Give me the luxuries of life and I will willingly do without the necessities." --Frank Lloyd Wright ___ 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] z3c.form: Default form content type
On Mon, Apr 11, 2011 at 8:02 AM, Sylvain Viollon wrote: > Or if you have a descent schema system that include this information. No, this really has to do with the widgets. A widget may well use Unicode data regardless of the expected result type. And most interesting schema leave a lot to be handled by widgets (think about selections from database-hosted sources, where the form values may be unicode but the selected values are objects). Multipart forms make more sense as a default. -Fred -- Fred L. Drake, Jr. "Give me the luxuries of life and I will willingly do without the necessities." --Frank Lloyd Wright ___ 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.lifecycleevent API
The zope.lifecycleevent package provides a pile of events that are generated in a lot of places. The implementation contains a single helper function, modified(), that appears to be intended for public consumption (it's not referenced in the package). However, it's not mentioned in the documentation or interfaces, and I can't find any references from other packages in my buildout egg cache (including 130 different zope.* packages, several versions of each). I was thinking of adding corresponding functions for the other events, but want to determine whether that function was really intended to be used publicly before proceeding. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] Fwd: FAILED : winbot / zope.testing_py_265_32
On Tue, Nov 30, 2010 at 3:12 AM, Adam GROSZER wrote: > zope.testing tests fail on windows. > The blamelist might not be real, because this is the first build. I think the blame-list is right. I think this requires an easy fix to the test. Will do. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] logrotation/logreopening in ZTK-based applications
On Wed, Nov 10, 2010 at 8:23 AM, I said: > There's a package called zc.signalhandler in the Zope Corporation > repository that I'll be open-sourcing. This is now available on svn.zope.org. The tests pass with Python 2.4, 2.5, 2.6, and 2.7. I've added a brief README.txt to show how it's used; there's a more extensive doctest inside the package. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] logrotation/logreopening in ZTK-based applications
On Wed, Nov 10, 2010 at 2:47 AM, Christian Theune wrote: > We have a ZTK-based app and found that the server provides neither > signal handling to rotate logs nor a zopectl command. Does anybody > remember wether this was ever built? Christian, If you want size- or time-based rotation, that can be configured directly using ZConfig. There's a package called zc.signalhandler in the Zope Corporation repository that I'll be open-sourcing. It'll let you include something like this in your zope.conf: usr2 ZConfig.components.logger.loghandler.reopenFiles That will let you re-open ZConfig-configured log files based on a signal. (The "myapp" is a turdly bit caused by using the same schema bits as sections in the zope.conf schema.) -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] Fun with vocabularies
On Thu, Oct 7, 2010 at 8:45 AM, Charlie Clark wrote: > This was the suggestion at the summit: > http://wiki.zope.org/ztk/ZopeSummit2010Summary Interestingly, I can't find anything that suggests "consolidation" by searching that page for "mail" or "list". Was that what "IRC/mailinglist rationalisation" means? -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] Fun with vocabularies
On Thu, Oct 7, 2010 at 8:35 AM, Charlie Clark wrote: > I thought we were consolidating the mailing lists? It is a developer's > rather than a user's question but I would agree not related to ZTK > development. Another consolidation? We already tossed the zope3-dev list. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] Fun with vocabularies
On Thu, Oct 7, 2010 at 8:21 AM, Charlie Clark wrote: > I was wondering whether it's possible to use callables for schema > vocabularies without registering them first? ... > I'm sure it should be possible but my weak and feeble brain has somehow > failed to solve the puzzle! Have you tried using a callable that provides zope.schema.interfaces.IContextSourceBinder? Looking at the code in 3.7.0 (the newest zope.schema in my egg cache), that should work out of the box. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] Zope Toolkit - 1.0a1 release
On Tue, Jul 6, 2010 at 11:00 AM, Tres Seaver wrote: > Given that ZODB3 and zope.app.container are still non-optional > dependencies of the package, I can't see any reason not to restore those > base classes. I mentioned it on IRC, but wanted to mention here as well for completeness: zope.pluggableauth 1.0.3 is out with the proposed change. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] zope.traversing's ILocation behavior
On Fri, Jul 9, 2010 at 9:08 AM, Hanno Schlichting wrote: > I think zope.dublincore causes the breakage in some zope.app packages. This one's a sticking point for a large application here as well (one where we're trying to move to the ZTK as the base). I think I'm sticking to zope.dublincore 3.6.0 on that for now. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] Zope Toolkit - 1.0a1 release
On Wed, Jun 30, 2010 at 3:47 PM, Hanno Schlichting wrote: > On behalf of the Zope Toolkit release team and the Zope community, I'm > happy to announce the first 1.0 alpha release of the Zope Toolkit. I've yet to hear any response to my post about non-backward-compatible classes: https://mail.zope.org/pipermail/zope-dev/2010-July/040898.html Is no one else concerned about the backward incompatibility introduced by zope.pluggableauth.plugins.session.SessionCredentialsPlugin? -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] zope.app.authentication
Sorry for bring an old thread back up, but it's relevant. On Tue, Jan 26, 2010 at 4:06 AM, Souheil CHELFOUH wrote: > The tests pass and nothing has been changed but the imports. Actually, the base classes for SessionCredentialsPlugin changed, and no longer include these: persistent.Persistent zope.app.container.contained.Contained These are probably good to retain. The later should probably be replaced with zope.container.contained.Contained, but the value is the same. Though simple, dropping this can affect existing applications in obscure ways, since adapter lookups are likely to produce different results. Are there any objections to adding these base classes back in? -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] Next bug day, on 2010-06-16 (Was: Schedule next bug day, please doodle until Friday)
On Sat, May 29, 2010 at 1:36 AM, Christian Theune wrote: > So I hope to see many of you on Wednesday 2010-06-16. I don't know who can add entries to the Google calendar with the weekly IRC meeting, but it would be nice if bug days were also added to that. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] Version bump question? Bikeshed here.
On Fri, Apr 30, 2010 at 4:10 PM, Hanno Schlichting wrote: > Going from 1.2 to 1.3 is a minor new feature release. Ok, if we're talking about changing the second number, this is fine. The wording "in a minor release" didn't connote "between minor releases" for me; I recognize I may just be a little pedantic on that point, though. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] Version bump question? Bikeshed here.
On Fri, Apr 30, 2010 at 3:57 PM, Hanno Schlichting wrote: > If it is intended to be backwards compatible and seems to be so, I'd > say go with 1.3. It sounds like a new package dependency, like we have > had many others in minor releases. Since when were new dependencies not considered features? -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] [Checkins] SVN: zope.dublincore/trunk/ Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.
On Fri, Apr 23, 2010 at 3:08 PM, Tres Seaver wrote: > Done. The 3.6.3 release is up on PyPI: I guess I should get out more; just noticed this thread. Changing the stored permission names is a big deal. If a permission gets stored with zope.dublincore 3.6.3, then an instance running 3.6.(0|1) can't use it. This creates a problem for rolling restarts, where a permission stored by an instance with 3.6.3 may be accessed by an instance using 3.6.1 (or an even older version). Here's another possible approach: - Keep the zope.app.dublincore.* permissions in 3.6.x, with forward-compatibility adjustments in the ZCML, using - Change the permission names and add backward compatible ZCML in 3.7.x: > and the trunk is updated to indicate a forthcoming 3.7.0 release minus > the BBB shims: If this even needs to be done, I'd like to see it be 4.0.0, because it's incompatible. This just doesn't seem valuable to me. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] Circular dependency hell.
On Tue, Apr 20, 2010 at 4:09 PM, Christian Theune wrote: > I think the two of us agreeing, right? You & I are. I think Jim's not (which is fine, of course). -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] Circular dependency hell.
On Tue, Apr 20, 2010 at 3:47 PM, Christian Theune wrote: > I don't know (or at least can't remember) all of the history of the > discussion about that, but I wouldn't argue about following standard > protocols. It *is* arguable that __name__ is a standard protocol. It's also not clear that our using it as we do is really the same thing. (And I don't think it's interesting to discuss whether we do the right thing or not.) > I think the issue is with that it's not standard protocol the way we use it > - at least I can't find our use of __bases__ documented in Python's > documentation[1] about __bases__ and thus have a hard time saying we're > following standard protocols. Our uses of __bases__ and __parent__ don't match Python, and there's a general BDFL proclamation that underware are for Python implementations (IIRC). While we can argue that our use is reasonable, the fact that there's reasonable dissent suggests something different would have been a better choice. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] Circular dependency hell.
On Tue, Apr 20, 2010 at 2:58 PM, Christian Theune wrote:
> zope.testing uses the attribute '__bases__' to store the information what
> the base layers are. __*__ are supposedly Python internal attributes.
> Specifically __bases__ is known to be used to store information which base
> classes a class has.
This sort of misdirection has, unfortunately, a long history in Zope 3
(and the various things that's become). Witness __name__. (There are
others, but most aren't *actually* used by Python implementations.)
Removing existing __*__ name ("underware") usage is probably
untenable, but I hope we can avoid extending our foolishness.
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Henry Miller
___
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] zope.test.doctest made into monkey-patches (Was: Circular dependency hell.)
On Tue, Apr 20, 2010 at 7:44 AM, Wichert Akkerman wrote: > You may want to move it outside the zope.* namespace to encourage that :) People interested in interfaces or component architectures don't seem to mind using zope.interface or zope.component; those get selected on their own merits with some frequency. I see no need to drop/replace the "zope." in the package name. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] Circular dependency hell.
On Fri, Apr 16, 2010 at 2:40 PM, Tres Seaver wrote: > :mod:`zope.testing.formparser` > Parses rendered HTML forms back to datastructures. Maybe useful > in tests which consume rendered output. > > No ZTK tests use this module. I believe this may be used in tests of some of the zope.app.* packages; I don't recall which ones. This predates zope.testbrowser; users should consider migrating to that. > :mod:`zope.testing.loggingsupport` > Enable assertions about how code uses Python's logging module. > > No ZTK tests use this module. > > Tests in :mod:`zc.buildout`, :mod:`zope.app.appsetup`, :mod:`ZODB`, > and :mod:`zc.lockfile` use this module. Many application tests use this module. > :mod:`zope.testing.module` > Support for jamming a dummy module into sys.modules, and getting > it out again in a testcase's tearDown.. > > Tests in :mod:`zope.copy` and :mod:`zope.container` use this module. > > Tests in :mod:`ZODB` also use this module Many application tests use this module. > :mod:`zope.testing.setupstack` > Support for chaining together teardown functions in a stack > > No ZTK tests use this module. > > Tests in :mod:`ZODB` and :mod:`zc.lockfile` use this module. Many application tests use this as well. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] SVN: ZConfig/trunk/setup.py correct metadata: I really did write this.
On Fri, Apr 9, 2010 at 10:43 AM, Tres Seaver wrote: > It seems reasonable to me that it *should* work, though I'm not sure how > to write the code which tests that. See my later follow-up as well. In particular, while it *may* be reasonable to set the ZF as maintainer, it's not clear that it's the right thing either. Why shouldn't some "Grok Team" be listed as the maintainer for the grok packages, with an appropriate email? That seems preferable to me. I think the *right* thing to do is update the copyrights to reflect the copyright ownership, but not to otherwise change package metadata. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] [Checkins] SVN: ZConfig/trunk/setup.py correct metadata: I really did write this.
On Fri, Apr 9, 2010 at 10:27 AM, Fred Drake wrote: > Setting the ZF as maintainer appears sufficient to appease the policy checker. Or not. The fixer script won't edit this, but the checker script will still whine about it. Changing the author to the ZF really isn't a good thing; if anything, the maintainer (and maintainer_email!) should be set to the ZF (and zope-dev?). Changing the author doesn't really make sense, and is falsification for many packages (certainly for all those created before the ZF existed). -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] Repository policy testing
On Thu, Apr 8, 2010 at 1:13 PM, Tres Seaver wrote: > I expect to see the list of flagged projects drop significantly on the > next run. Is this list available somewhere for us to review? -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] env var support for zc.buildout
On Thu, Apr 8, 2010 at 9:03 AM, Christian Theune wrote: > The "special" that I was referring to was the fact that you don't have to > spell a recipe name for that section (like the buildout section). There are many times you can have a section that isn't a part; the buildout section is just that, as is the section named by buildout:versions. Only parts need to have the recipe specified. *If* buildout should support some special "environment" section, I'd hope that it was explicitly referenced by something like buildout:environment. This would avoid the problem of breaking existing buildouts that already use sections with whatever conventional name arises for this feature. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] env var support for zc.buildout
On Thu, Apr 8, 2010 at 8:24 AM, Christian Theune wrote: > Maybe a specialised part-name, like versions would be helpful so that > buildout could pre-populate that part during initialisation and then > allow configurations to override individual values. It's probably worth mentioning that "versions" isn't a specialized part name in any sense; the name has to be explicitly mentioned in buildout:versions, and could be named anything. The use of explicit section references instead of a lot of "magic" section names is a good thing about buildout. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] Segfault in zope.configuration
On Wed, Apr 7, 2010 at 9:29 AM, Martin Aspeli wrote: > I have a slight suspicion that lxml is involved somewhere. I've managed > to make it crash reliably simply by doing a parse of an XML file, and I > think such a parse may be happening as a side effect of a module import > caused by that very ZCML file. If it can be nailed on lxml, I'll be happy. :-) Not because I want lxml to be at fault so much as I want Expat not to be. Invoking lxml as a side effect of import seems like it should be fairly easy to identify and comment out for testing purposes; if the ZCML configuration can then complete, you've implicated your suspect. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] Segfault in zope.configuration
On Tue, Apr 6, 2010 at 10:25 PM, Martin Aspeli wrote: > So this is still in pyexpat C code as far as I can tell. :-( This is saddening. I've not managed a 64-bit sandbox, which I suspect is what I really need to debug that. Will shoot for this weekend, since last didn't pan out. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] zc.buildout "not upgrading" issue (was Re: RFC: 3.4.1 KGS?)
On Fri, Apr 2, 2010 at 10:51 AM, Marius Gedminas wrote: > Maybe it would make sense to add a command-line option for buildout to > override version pins? > > bin/buildout -t 2 -c configfile --pin zc.buildout=1.4.3 \ > --pin setuptools=0.9c11 > > with "--pin zc.buildout=" meaning "use latest version, disregarding the > pin in the config file." Already implemented: bin/buildout -t 2 -c configfile \ versions:zc.buildout=1.4.3 \ versions:setuptools=0.9c11 -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] Segfault in zope.configuration
On Thu, Apr 1, 2010 at 2:17 PM, Tres Seaver wrote: > /me is deeply suspicious of *any* distro-provided python, ever. I'm also suspicious of 64-bit builds, given that I'm not using one on my dev machine. I've picked up the OpenSuSE installation ISOs; hopefully that's close enough to the SLES distributions that I'll be able to construct useful VMs. Martin: If I can't manage a useful 64-bit VM, I'll probably send you a script to try out. It'll likely be this weekend before I can really dive in. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] Segfault in zope.configuration
On Thu, Apr 1, 2010 at 7:29 AM, Martin Aspeli wrote: > I'm pretty sure it is. The pdb rabbit hole ended at pyexpat.c. I can't > see what's going on there, but when I did 'r' it blew up. If you can point me at the ZCML file you were trying to parse (or email it to me privately if it's not in a public repository), I'd be glad to see what I can turn up. I'll also need to know what version of Python you're using. Thanks! -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] Segfault in zope.configuration
On Thu, Apr 1, 2010 at 6:07 AM, Martin Aspeli wrote: > Any tips on how to debug or similar experiences would be appreciated! If you're on some Unix flavor, you should be able to deconstruct the return code from the runzope process to determine if the app was killed by a signal and, if so, which. If it's a segfault, you should be looking for signal.SIGSEGV. I'd be very interested in hearing if Expat is implicated. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] Optional C extensions
On Tue, Mar 9, 2010 at 10:53 AM, Baiju M wrote: > Any idea how difficult it is to create optional C extensions > for these packages: zope.proxy will be fairly difficult to implement without C. Alternate Python implementations may be able to use extensions written in other ways, however. (Java for Jython, C# for IronPython, etc.) -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] Summary of today's developer meeting
On Tue, Mar 2, 2010 at 11:32 AM, Christian Theune wrote: > here's my first shot at a summary of today's meeting. Thanks, Christian! I definitely appreciate this summary, since I was visually impaired at the time of the meeting (and still am, but it's returning...). -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] New Zope 3 name: BlueBream
On Wed, Jan 6, 2010 at 10:44 AM, Hermann Himmelbauer wrote: > Microsoft, really? Interesting, I personally think about IBM (Big Blue)... The Blue Screen of Death definitely signifies Microsoft to me! That also qualifies as a serious bad-vibes indicator. ;-) -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] removing zope.app from the ZTK
On Tue, Dec 29, 2009 at 6:11 PM, Martijn Faassen wrote: > * the ZTK is new, therefore the ZTK doesn't need to care about Zope 3 at > all. I'm strongly in this camp. The other camps can readily be supported on top of this view of the ZTK by providing new names for higher-level toolkits and applications. Without the scope reduction on the ZTK, there's not really any motivation for it. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] moving the zope.app.* packages out of the ZTK: towards a plan
On Tue, Dec 29, 2009 at 4:19 PM, Martijn Faassen wrote: > Let me sketch out some ideas for a plan: Thankfully you started getting this done while I was distracted from my email by a meeting. :-) I'll send this anyway, since there's probably a few points of contention still, though I don't think they're large or difficult to work out. > * we create a new project, zopeapp, with the same structure as the > zopetoolkit (sans documentation) +1 > * we pull the zope.app.* packages from the ZTK and move them into zopeapp. +1 > * we make sure we have a way to regularly run the zopeapp tests in > conjunction with the ZTK. -1 (not the problem of the ZTK maintainers; anyone who cares can start from the machinery used for the ZTK, if they exist) > * we then move towards a release of ZTK 1.0 (see Hanno's mail for lots > of things we need to work out) +1 > * we also release zopeapp 1.0 in conjunction with it. This is just a > backwards compatibility KGSish thing. We explicitly don't strive to > document it, etc. -1 (again, not the problem for the ZTK maintainers; let's let someone who cares worry about what constitutes "1.0" or any other release) > * we announce that we strive to deprecate what's in zopeapp 1.0 and that > we expect users to shift to use ZTK packages as much as possible and > report back any difficulties they have with this. -1 (let those who care about the packages in the fledgling zopeapp decide what to do with them) > * this will help us determine whether there is still useful code left in > zopeapp that we wish to salvage into the ZTK or otherwise maintain. -1 (no need) > * this will also help us determine which packages in zopeapp are more > generally useful, and strive to isolate them from the rest of zopeapp. > zope.formlib is an example of this. Packages not in the ZTK can be considered for adoption into the ZTK based on the policies of ZTK maintenance; no need for a separate review step as part of splitting things up. > * depending on our experiences in Zope 2, Zope 3 and Grok apps we can > decide whether we can put zopeapp in the deep freeze: not maintain it > anymore. +1 that it's not a ZTK issue. There's no action for the ZTK maintainers in this. > * we then also look into shunting away the zope.app.* packages from the > top-level SVN into an "this is old stuff area" by that time. -1 (no need) > Note that we also have a long-standing idea of a "wider KGS" which > contains the ZTK plus perhaps zopeapp plus more, such as z3c.form. This > is a related exercise. Again, this isn't a ZTK issue, but a consideration for those interested in those higher-level projects. > Once we have some discussion we can hopefully flesh out this plan, put > in some dates and such, and put the plan in the Zope Toolkit documentatino. -1 (such projects should not be incorporated into the ZTK project) -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] removing zope.app from the ZTK
On Tue, Dec 29, 2009 at 4:04 PM, Martijn Faassen wrote:
> But right now we need to provide some guidance for how people can move
> away from these packages in a sane manner. And we should make sure we
> continue to test the zope.app.* packages when we make ZTK changes, for
> the time being.
>
> Let's work out a plan and a timeline.
I think we disagree as to the scale of what's needed still.
I'd be happy to see a copy of the ZTK tree get made to some
recognizable name ("ZATK", for "Zope App Toolkit", would suffice), let
Hanno commit his removal of the zope.app packages from the ZTK, and
then make the ZATK refer to that version of the ZTK instead of
including it directly.
The only timeline that's needed is the order of the commits.
If there's anyone who wants to maintain the new bastard-stepchild,
they're free to step forward. There's no obligation on the part of
the ZTK maintainers to do that, nor should there be.
That's the whole point.
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Henry Miller
___
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] removing zope.app from the ZTK
On Tue, Dec 29, 2009 at 10:39 AM, Wichert Akkerman wrote: > It seems that you want to have a 'ZTK+' which aims to be backwards > compatible with Zope 3 but is somehow not Zope 3 itself. That is > something that not everybody appears to be interested in judging by the > lack of progress on Zope 3 itself, but if you want to pursue that I do > not see any reason for you not to do that. But it should separate from > the ZTK. Agreed; the lean & mean ZTK is more interesting than this ZTK + zope.app construct. Creating a second known-good-set construct based on the ZTK and adding the selected zope.app package sounds like a straightforward task. It should be able to reuse the testing policies with little or no change. I agree with Martijn's desire for caution, however. This split should be done, but this is a split, not a simple removal of the zope.app packages without setting up this ZTK+ construct. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] windows newslines in doctests
On Mon, Dec 28, 2009 at 4:57 PM, Chris Withers wrote: > I think if your development environment involves Windows checkouts, they > happen more often that you'd like, especially when a single Windows > developer doesn't have svn:eol-style set for all types that end up being > doctests. It's interesting to note that Python 2.6's doctest doesn't use universal newlines, but zope.testing.doctest. With the recent move to use the standard library's doctest, we may be seeing more of this. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] PyPI access for zope.contenttype
On Mon, Dec 28, 2009 at 4:28 PM, Hanno Schlichting wrote: > Sure, you got it :) Thanks! -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] PyPI access for zope.contenttype
Can someone set me up with PyPI privs for zope.contenttype? Thanks! -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] Avoid deprecation warnings in the testrunner
On Thu, Dec 24, 2009 at 10:52 AM, Zvezdan Petkovic wrote: > Of course, it may be worth trying if there is a critical mass of supporters. Alternately, there could be a way of extending the standard doctest to achieve this "feature" without pushing it into the standard library. I'm ambivalent on the value of the feature itself. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] implementing zope.component 4.0
On Wed, Dec 2, 2009 at 8:42 AM, Gary Poster wrote: > You are arguing for the unification of utilities and adapters? No. I'm arguing not to conflate utilities with the singleton pattern or adaptation with ownership of the resulting adaptation. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] implementing zope.component 4.0
On Wed, Dec 2, 2009 at 2:21 AM, Thomas Lotze wrote: > To be honest, I just don't see why this whole singleton business shouldn't > be orthogonal to the concepts of the component architecture. Well said. If an application cares about singleton creation or ownership of factory-returned objects, it can describe those requirements using interfaces. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] implementing zope.component 4.0
On Tue, Dec 1, 2009 at 11:34 AM, Martin Aspeli wrote: > I think > that logically, these are two different concepts that meet two different > sets of use cases. Agreed here. This is essential to this discussion. I've been quite surprised that there are so many who argue to unify these ideas. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] implementing zope.component 4.0
On Mon, Nov 30, 2009 at 5:14 PM, Lennart Regebro wrote: > True. For me utilities are tools. Like CMFs portal_whatever. But in > Zope3 even small stupid singleton objects are utilities in some cases, > and that is confusing for a beginner. I wonder how many typical Python programmers know the term "singleton". Though it's not unusual for there to be exactly one instance of a class in a process, it's pretty unusual to think about that as a valuable aspect of a class. Which for the traditional definition of singleton, it very much is. -1 for calling utilities singletons, since that has nothing to do with their usage. +1 for calling them utilities, since that has everything to do with how they're used. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] Proposal: cleaning up the content-type story
On Wed, Oct 7, 2009 at 11:27 AM, Thomas Lotze wrote: > OTOH, even with good usability I'd rather not have rights for packages I'm > not interested in, just to be able to deny responsibility if anything goes > wrong with one of them. It's entirely reasonable for maintainers to have rights for the packages they work on. My objection was to learning about large numbers of packages when someone handed me rights to them on PyPI. Not *exactly* the case here, but I firmly stand against wildly spraying permissions where they're not wanted. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] Proposal: cleaning up the content-type story
On Wed, Oct 7, 2009 at 11:10 AM, Hanno Schlichting wrote: > If someone would document srichter's magic grant-all-powerful PyPi > script, I'd run it :) That's a horrible thing to do to somebody! Note that I'm not smiling, either. It's too easy to grant people access to way too many packages that way. Somebody ran it for me, without my knowledge, and I learned about a lot of packages I'd never heard of before. That just makes PyPI harder to use when updating something I *am* actually a maintainer for. On the other hand, it got me to prod for a fix to the PyPI bug that didn't let me remove myself from those projects. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] Proposal: Determining packages which are in the ZTK
On Fri, Sep 18, 2009 at 11:53 AM, Tres Seaver wrote: > - - Any package which depends on a zope.* package which is *not* part > of the ZTK should itself be removed from the ZTK. +1 > - - As a corollary, any package which depends on any other "probationary" > package is automatically probationary itself. +0 > - - (A little more speculative) Any package which doesn't have one or > more clearly-identified maintainers should be probationary. -0 -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Fri, Sep 11, 2009 at 10:30 AM, Gary Poster wrote: > Also, since I'm also in the "setup.py should be able to specify > minimum versions" camp (admittedly unlike others, such as Benji, to my > continued surprise) I agree with you on this point; it's quite useful for setup.py to be able to specify such requirement constraints. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Fri, Sep 11, 2009 at 8:53 AM, Martijn Faassen wrote: > So, could you please follow this policy for ZTK packages in SVN? I suspect it would help if packages that are part of the ZTK have that indicated somewhere convenient, like near where the version number is specified in the setup.py file. Possibly with a link to the ZTK release policies. When making changes, we're often considering the relevant packages in isolation or in the context of our own applications, so a pointer to additional policies that apply is helpful. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
2009/9/10 Benji York : > 3) so superfluous version bumps on the trunk s/so/no/ -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] chameleon.core removes the meta http-equiv="content-type" tag
The is used to identify the encoding of the file providing the template. This has nothing to do with the encoding of the output resource, which is determined by the application. In the case of the Zope publisher, Unicode output from the template is converted to UTF-8 by default, and the charset is set appropriately for text/* content types. This gets to the basic problem that templates have both input and output concerns, and there's currently no clean way to separate the two without additional syntax or metadata support. There's no one way to handle this; zope.pagetemplate.pagetemplatefile contains specific choices which made sense at the time; I think these are still reasonable choices. Existing applications may well require the current behavior, so it's unreasonable to change that, regardless of how attractive a new set of choices may appear. The right way to make new choices is to create a new class that embodies those choices, or which allows runtime configuration, and use that as appropriate. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] Subversion externals versus mirroring
On Wed, Sep 9, 2009 at 8:31 AM, Christian Theune wrote: > As a side effect this will also make svn/svn+ssh work in a nicer way > (IMHO) as the externals will follow the protocol of what you used for > checkout. I like that externals to svn:... are read-only, though I don't know offhand whether we have a policy about this. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] List of packages in the ZTK
2009/8/6 Fabio Tranchitella : > Am I correct saying that your idea is to restrict the ZTK to the packages > defined as the intersection of the dependencies of zope2, zope3 and grok? > > ZTK = intersection ( zope2-dependencies , zope3-dependencies, grok ) That's my understanding of what Tres wrote. > I don't think this definition fits our needs, but my skills on gron and > zope2 are too limited to bring counterexamples. This, however, is more readily achievable, and provides a good foundation for each of the other projects mentioned to build from. This sounds like the right starting point to me. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] test setup layer sorting
On Mon, Jul 13, 2009 at 3:36 PM, Marius Gedminas wrote: > Fortunately, the NotImplementedError in ZCMLLayer's tearDown is just a > precaution, 99% of the time it is sufficient to run CleanUp.tearDown > to get the global state restored to its pristine condition. Keep in mind that a number of commonly-used ZCML directives stamp interfaces on classes; these aren't cleaned up with the general tear-down. If each layer stamps the same interfaces on the same classes, the only issue is ensuring that unit tests run first. If, however, you have different layers that may apply different sets of interfaces to different classes, you're may be relying on the process boundary as part of the required isolation. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface 3.5.2 release
On Wed, Jul 1, 2009 at 12:30 PM, Hanno Schlichting wrote: > Just did that for Python 2.4 to 2.6. Thanks, Hanno! -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.interface 3.5.2 release
I just released zope.interface 3.5.2, which adds only this bug fix: - BaseAdapterRegistry.unregister, unsubscribe: Remove empty portions of the data structures when something is removed. This avoids leaving references to global objects (interfaces) that may be slated for removal from the calling application. I've made a source distribution available via PyPI: http://pypi.python.org/pypi/zope.interface/ Windows users would likely be thankful if someone with the appropriate tools and know-how to build Windows binary distributions were to do so and upload those to PyPI as well. Enjoy! -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zc.recipe.cmmi shared builds
On Tue, May 12, 2009 at 10:56 AM, Wolfgang Schnerring wrote: > Looks good so far. Could someone do a release of zc.recipe.cmmi > (or grant 'wosc' pypi access so I can do it myself)? Done. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.intid/trunk/ - Remove a dependency on ``zope.container.contained.Contained``
On Fri, May 15, 2009 at 2:57 AM, Chris McDonough wrote: > It's a partial step towards getting rid of a dependency that zope.intid has on > zope.container. I'm thinking that maybe that IContained interface belongs in > some other package (e.g. maybe zope.contained). That Container base class > is.. > uh.. not complicated, so even if we never do get rid of the zope.container > dependency completely, it really doesn't harm anything to not use Contained. > Unless you have some nostalgia for it. ;-) At the rate we're going, every class and every interface is going to be in a separate package. Keeping the dependency graph clean is great, and there's plenty to do there. But there's also something to be said about being able to keep a substantial portion of it in your head. The cleanliness of the graph isn't so important if most users still can't understand just because there are so many pieces that they wouldn't normally use directly. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.annotation/trunk/setup.py Whitespace fixes
2009/4/2 Marius Gedminas : > looks like a mistaken assignment of a tuple to a name, while > > setup( > > foo=bar, > > ) > > looks like a function call. Agreed; the common use of spaces around the equal signs in setup.py is a holdover from Greg Ward's coding style (Greg being the original author of distutils). AFAICT, they remain prevalent in setup.py because most new setup.py files are generated by copying an existing setup.py from another project. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT attributes and ""
On Wed, Mar 18, 2009 at 7:59 AM, Roger Ineichen wrote: > As far as I know it is valid to skip attributes for empty values > but for some attributes it is not valid to use empty values. Let's not use the term valid in this context, as it's pretty overloaded here. In the general case, there's no way to know what string values can be dropped silently, and it's wrong to assume that it can be done safely. Using a special value (None, a.k.a. nothing in templates) is the only reasonable indicator that an attribute should be dropped. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT attributes and ""
On Tue, Mar 10, 2009 at 9:08 AM, Malthe Borch wrote: > How do folks feel about changing this behavior in ``zope.pagetemplate``. The change would need to be in zope.tal. I'm ambivalent; while it makes sense to me in isolation, the affect on existing templates is undesirable, and compatibility is a huge deal for this bit of machinery. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] setup.py "extra" dependencies
On Thu, Mar 5, 2009 at 1:43 PM, Martijn Faassen wrote: > * we shouldn't create any new "extra" dependencies from now on. +1 > * we should investigate ways to remove the need for 'extra' dependencies. +1 > I therefore think zope.app.testing is one package we should be looking > to get rid of eventually by splitting it up among a lot of 'testing' > modules in individual packages. This way we won't have zope.app.testing > sitting at an edge against our whole dependency tree. +1 -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Coding style clarifications
On Thu, Feb 19, 2009 at 11:03 AM, Jim Fulton wrote: > BTW, I strongly discourage from imports. (I didn't always have this > opinion, but have seen the error of my ways. Thanks to Fred Drake for > nudging me in this direction.) IMO, this is wildly more important than > any of the issues raised in this thread. You're welcome. :-) -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Can somebody upload a zope.app.zcmlfiles 3.5.3 release?
On Thu, Feb 5, 2009 at 12:52 PM, Tres Seaver wrote: > I'm fixing dependent packages broken by my changes: could you add me to > zope.app.container as well? Done. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.security changes
On Thu, Jan 29, 2009 at 4:01 AM, Martijn Faassen wrote: > I believe it'd be nicer to extract any ZCML related stuff from > zope.component at some point and put it into zope.componentzcml or > something like that. We could then decide to move the and > directives in there as well. +1 This makes a lot more sense to me than having the ZCML support in either zope.component or zope.security. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] can these wrong DEPENDENCIES.cfg files be removed?
On Tue, Jan 27, 2009 at 6:01 AM, Dan Korostelev wrote: > AFAIK, these files are for (pre-egg, no-longer-used) zpkg tool. They > are removed in zope.app.renderer's trunk, BTW. I certainly hope no one is relying on that old tools! The following files are all from that experiment, and are present at many points in the "sumo" checkout, so many of the satellite projects are affected: DEPENDENCIES.cfg PACKAGE.cfg PUBLICATION.cfg SETUP.cfg -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
On Wed, Dec 17, 2008 at 6:36 PM, Tres Seaver wrote: > If we just leave the name importable from the old location, what is > hurt? The major downside is that people won't learn about the new > location. I consider this to be less an issue than the two problems I > outline above. Agreed. Moving things around in public packages without preserving backward compatibility creates real nuisances, and just not generating warnings avoids lots of pain. This doesn't mean that you can't teach people about new locations; you just don't need to do it every time they run your code. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zc.sourcefactory/trunk/buildout.cfg color by default
On Mon, Dec 8, 2008 at 10:56 AM, Benji York <[EMAIL PROTECTED]> wrote: > This setting apparently causes problems for people who use Emacs, so > for zope. and zc. packages at least, we don't use --auto-color. I've been using this under Emacs for a while, and haven't experienced any tool-related problems with colorization. I *have* generally objected to adding settings like this in buildout.cfg: some of us (including myself!) think it makes the output harder to read. The only "right" way to deal with this seems to be to either: - require users wanting color to ask for it from the command line, or - add configuration support, so this can be set per-user, rather than polluting buildout.cfg for everyone. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.security and zope.location depend on each other
On Fri, Nov 14, 2008 at 9:54 AM, Joachim König <[EMAIL PROTECTED]> wrote: > This is only required at runtime, so this is not a (circular) build or > install dependency, > but as the NetBSD-pkgsrc build infrastructure wants to generate the > .pyc/.pyo files > at installation time, I still have a problem with that. You should not be importing any of the Python files to generate the .pyc/.pyo files at installation. You should be using compileall.py (from the Python installation) or something similar to create the .pyc/.pyo files. > So my question is: Is this circular dependency really needed or could it > be avoided > somehow? It at least looks a bit strange to me. Two components should > not depend > on each other, or am I missing something? Hopefully it can be avoided, but this isn't a problem for .pyc/.pyo generation. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Increase logging for zope.app.generations
On Mon, Nov 10, 2008 at 3:31 AM, Christian Theune <[EMAIL PROTECTED]> wrote: > I'd like to increase the logging for zope.app.generations to output an > INFO message when performing a generation. +1 -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.sendmail/trunk/src/zope/sendmail/mailer.py try again with catching sslerror, thx Jens
On Tue, Oct 7, 2008 at 11:00 AM, Zvezdan Petkovic <[EMAIL PROTECTED]> wrote: > However, are we _certain_ that the socket is closed after this? smtplib does *not* close the client socket if there's an exception while sending the quit message or processing the response. It could be best if connection..close() were called in the case of an exception. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results
On Tue, Sep 9, 2008 at 2:37 PM, Dieter Maurer <[EMAIL PROTECTED]> wrote: > The syntax would be a bit more cumbersome -- but on the other > hand, it would be more explicit :-) Seems to me zope.component.getMultiAdapter(...) is sufficient as-is, and shares the benefit of explicitness. That's sufficient for me. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results
On Sun, Sep 7, 2008 at 3:29 PM, Chris Withers <[EMAIL PROTECTED]> wrote: > I can't see any problems with this, can anyone else? There's the backward-compatibility issue, which is a showstopper. There's plenty of code that does this: adapter = package.interfaces.IFoo(object, None) Changing the signature as you describe would break all code that does this. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zc.recipe.testrunner 1.1.0 requires zope.testing 3.6.0, but not released
On Thu, Sep 4, 2008 at 8:16 AM, Martijn Faassen <[EMAIL PROTECTED]> wrote: > Does the hidden status explain it not being picked up by buildout? > Anyway, sorry for getting confused there. No; the "hidden" bit only affects the normal PyPI user interface. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Dependencies and future of zope 3
On Wed, Sep 3, 2008 at 1:47 PM, Benji York <[EMAIL PROTECTED]> wrote: > Maybe we should create a new namespace package for "browser" code. > > How about "zope.browser"? Heh. That's just sooo long. Perhaps it should be "zobr". :-) -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] "zipped" versus "unzipped" eggs (was: Re: SVN: Zope2.buildout/trunk/ Don't pin setuptools.)
On Sat, Aug 30, 2008 at 2:03 AM, Dieter Maurer <[EMAIL PROTECTED]> wrote: > However, I am not sure whether our observations for a single > large zip (in fact, we use two: one for our application, the other for > Python's > runtime library) is valid for the case of many small zipped eggs. The single-large-zip and the many-small-zips are distinctly different; the zip-import support was intended to support the single-large-zip (or small-number-of-zips) cases. Having many small zips is not a win at all. (Don't recall if there's a real penalty over many unzipped directories.) -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.dublincore/trunk/ Move test-dependencies to 'extras'.
On Fri, Aug 29, 2008 at 5:26 PM, Malthe Borch <[EMAIL PROTECTED]> wrote: > I didn't know there was a controversy, but I do remember that there was > consensus that ``extras_require`` is not the most elegant solution. Oh, there is! > If you can advise a different way to avoid pulling in > ``zope.app.testing`` I'm happy to revert the change; otherwise I think > we should live and let live with it since it at the very least does the job. There's no good way to avoid dependencies like zope.app.testing; because that's part of the test environment, the tests won't show whether there are problems when it's removed. If you want to fly what you test, test dependencies can't be eliminated. I'd suggest reverting the change for now. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Move test-dependencies to 'extras'.
On Fri, Aug 29, 2008 at 5:13 PM, Malthe Borch <[EMAIL PROTECTED]> wrote: > Log message for revision 90599: > Move test-dependencies to 'extras'. This is a controversial change; can we avoid making changes like this until a policy is agreed upon? The controversy surrounding this has been discussed on zope-dev several times; I don't want to rehash it *right now*, since we all have things we need to get done. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.form: Make "no value" always available?
On Thu, Aug 21, 2008 at 8:45 AM, Thomas Lotze <[EMAIL PROTECTED]> wrote: > If someone gives me access to the package on PyPI (username: tlotze), > I can also upload it there. Done. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: bad "zope.size" to remove from PyPI
On Sat, Aug 2, 2008 at 9:27 AM, Benji York <[EMAIL PROTECTED]> wrote: > Still, it's likely that someone was using it and their buildouts are now > broken. We should have instead generated a proper release with a higher > version number and left the dev release alone. Yes. It would be even better if PyPI refused registrations of dev versions. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] New zope.interface 3.4.2 release
On Sat, Jul 26, 2008 at 7:36 AM, Hanno Schlichting <[EMAIL PROTECTED]> wrote: > Would someone (Jim, Philikon, Fred) be willing to do a new zope.interface > release or give me access rights on PyPi to do it myself? I've added Stephan Richter and Andreas Jung to the project on PyPI, since I could remember their ids. Either they or I can add you if you provide your PyPI id (or if they remember it first). -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] BdbQuit and the testrunner
I often find that I debug problems by inserting a pdb.set_trace() in code, and then quitting the debugger with "q" once I've gathered information I need to make code changes. This causes a BdbQuit exception to be raised and propagated to the test runner. The resulting traceback isn't actually useful. I'd like to change the test runner to capture BdbQuit and print a message to stdout before exiting instead of dumping the traceback. Any reason this would be a bad idea? -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Tesing a module against against dependencies in different versions
On Wed, Jul 16, 2008 at 2:59 PM, Andreas Jung <[EMAIL PROTECTED]> wrote: > we maintain some modules that should work against different versions of > dependent module. E.g. my z3c.sqlalchemy module should work with > > Sqlalchemy 0.3.X and zope.interface 3.0.X > or > SQLAlchemy >=0.4.X and zope.interface>=3.3.0 > > The codebase right works with both combinations. I am not sure how test such > configurations automatically because the dependent modules and their > versions are fixed within the setup.py. Is there some way together with > Buildout, zope.testing & friends? This remains a tricky case. :-( I suspect the best thing is for the setup.py not to mention any of the packages for which there are different names, and the versions should be specified in the buildout.cfg as requirements for separate test scripts. I.e., zope.interface could be mentioned in setup.py (sans version), but the sql alchemy packages would not be since the names differ. You could then create test scripts like so: [test-one] recipe = zc.recipe.testrunner eggs = z3c.sqlalchemy Sqlalchemy >=0.3.0, <0.4.0 zope.interface >=3.0.0 [test-two] recipe = zc.recipe.testrunner eggs = z3c.sqlalchemy SQLAlchemy >=0.4.0 zope.interface >=3.3.0 I expect you could come up with better names than test-one and test-two; I'm creativity-challenged at the moment. :-) -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: No events in zope.annotation
On Wed, Jul 16, 2008 at 11:46 AM, Fred Drake <[EMAIL PROTECTED]> wrote: > I don't see any need for a way to suppress them, since they shouldn't > trigger any subscribers for the normal containment events. Based on some discussion here, I realize that my position may not be terribly clear. Just to make myself clear: - Do what you want with the factory; I don't want it used (directly or indirectly) from the ZC codebase (not that I get to set policy or anything). - I think it's reasonable for an IAnnotations provider to generate annotations-related events for add/replace/remove operations. - I see no reason that the default IAnnotations implementations generate events; we want to avoid firing events all over the place just so we can ignore them. The last, in particular, needed to be stated explicitly. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: No events in zope.annotation
On Wed, Jul 16, 2008 at 11:33 AM, Roger Ineichen <[EMAIL PROTECTED]> wrote: > Even worse, I store objects in the annotation wich are added to > a real IContainer as items somewhere else. This objects are created, > added etc. already in the other container and provide locations > from there. Only the factory should generate object created events; it sounds like you're not using that. The added/replaced/removed events should not be the containment events at all, though making them object events should be acceptable. I don't see any need for a way to suppress them, since they shouldn't trigger any subscribers for the normal containment events. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: No events in zope.annotation
On Wed, Jul 16, 2008 at 10:45 AM, Stephan Richter <[EMAIL PROTECTED]> wrote: > But I agree. The system supports simple type and that is one of the use cases. > While I originally wanted to add at least 2 of the events to the IAnnotations > adapter itself, I agree with you that the overhead penalty might be too > severe. I don't think I said anything about a penalty on this, though that could certainly be an issue. I doubt it really is, though. > With this in mind, I am modifying my proposal to add 2 event notifications to > the factory only to produce a function like this (it is the result of calling > the annotation factory): My preference would be that these events would not be specific to the factory, keeping the model clean. > I am torn whether the created event should be a annotation specific or not, > because an object is not an annotation until it has been added as one. The created event should not be annotation-specific, for the reason you cite -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
