Re: [Zope-dev] zope.testing.doctestunit and BBB

2009-12-21 Thread Lennart Regebro 
On Sun, Dec 20, 2009 at 23:55, Marius Gedminas mar...@gedmin.as wrote:
 I don't know if 'doctestunit' was ever a part of the official
 zope.testing API, I just know that I've learned to use

I've looked through the history of doctestunit, and it seems like it
once was. This was changed 5 years ago, and doctestunit was left with
BBB imports without comments and without deprecation.

Then they was removed in a cleanup, as they simply was unused imports.

This probably should be reverted. I'll add them back with
deprecations, and also deprecate zope.testing.doctest in general.

-- 
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python-incompatibility.googlecode.com/
+33 661 58 14 64
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] A summary of Interfaces vs ZCA concepts

2009-12-21 Thread Thomas Lotze 
Hi,

this is a long message with a lot of replies to things that I don't agree
with. Since I realize that making those points over and over again doesn't
get us anywhere, I'd like to point out first that I'm going to implement
Martijn's suggestions anyway on one of my branches, hoping that seeing
more actual code to talk about might help getting to more consensus.

Martijn Faassen wrote:

 * It'd be nice if __call__ came back with a LookupError instead of a
 TypeError, but how to get from A to B without breakage?
 
 It's not possible without breakage.
 
 Unless we create a zope.interface specific LookupError which subclasses
 both the built-in LookupError and TypeError. zope.component's
 ComponentLookupError should subclass this special LookupError then.

Technically true, so my statement was admittedly too strong. I just don't
feel comfortable with the idea, which may well be just because it's the
let's make both exceptions work sowmehow solution to me instead of the
clear change I thought we were considering. OTOH, it's not that big an
issue either, so I guess I'd be fine with it.

 * the methods can be on zope.interface even if zope.component isn't
 installed. They will behave as if the component registry is empty.
 
 This isn't covered by the consensus you mentioned above as far as I'm
 concerned.
 
 Yeah, I put that in so we can reach consensus on it. I thought Tres had a
 good idea going on there that makes the plugin behavior a lot cleaner.

Hm, I can't help feeling pushed into this. While this plugin stuff is
indeed nice *assuming* that we want all the zope.component concepts in
zope.interface, it doesn't contribute to the decision about *whether* we
want that in the first place.

 IFoo.adapt(context) raises LookupError, unless the context provides
 IFoo, in which case it returns context.

 IFoo.adapt(context, default=default) returns default unless context
 provides IFoo, in which case it returns context.

 IFoo.utility() raises LookupError.

 IFoo.utility(default=default) returns default
 
 I think looking at that API explains why we have trouble with having
 stub methods defined by zope.interface: these methods contain enough
 information about component concepts to blur the distinction between
 zope.interface and zope.component, but they still lie about the actual
 method signature.

 I don't understand you: why do you say they lie about their method
 signature? They should have the same signature and have a well-defined
 behavior if zope.component is not installed: there is nothing registered
 at all. zope.interface provides a plugin point that allows one to plug
 lookup behavior into it.

When I wrote that, I was assuming that we were talking about patching
interfaces with methods that have zope.component's full lookup semantics,
including `name` and `context` parameters - which abviously would change
the signatures. If we're talking about something that doesn't add those
parameters, there's no lie involved but I don't see how our lookup methods
could then access the full feature set of zope.component's lookups.

 In that case, I want the real contract to be in zope.interface. That's
 where the methods are, after all. We need to talk about the concept of an
 adapter and a utility briefly in zope.interface and defer to
 zope.component as the most common implementation. We already have this
 kind of behavior going on anyway with __call__() (even though not
 documented!).

Well, we obviously disagree completely about this. The existing __call__
method is neither a good example of a zope.component lookup API, nor do I
think that it was fortunate to wire up the adaptation concept in
zope.interface through __call__ in the first place. I'd rather try to
loosen this reference to component concepts than use it as a reason for
adding more.

 You'll have to go into more detail. Why does it feel wrong to you?

Because it is just another way of encoding the zope.component details
within zope.interface. I would love to add a plugin API that is generic
enough to apply equally to other uses of interfaces than component lookup,
and that would allow implementations of component lookup with different
concepts and different lookup methods than those of zope.component.

 Why is it a problem that the zope.interface package gains knowledge about
 adaptation (which it always had, anyway)

(and which, IMO, it shouldn't have in the first place)

 and utility lookup?

Because if we're serious about making interfaces more of a language
feature, they should at their core be reduced to *being* mostly
information (maybe with a bit of verification code) instead of extended to
*doing* things that derive mainly from *our* particular ways of using them.

 Because to
 the user of those methods on Interface, it looks exactly like the
 packa
 does have such knowledge. We shouldn't lie.ge

I don't think that we lie as long as we state that we have a plugin system
of any kind (including monkey-patching, for the sake of

[Zope-dev] zope.schema

2009-12-21 Thread Godefroid Chapelle 
Hi,

Jean-Francois and I made a few improvements to zope.schema.

Would it be possible to get a new release ?

Or to give us access on Pypi so that we can make it ourselves ?

Thanks
-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be
___
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] A summary of Interfaces vs ZCA concepts

2009-12-21 Thread Chris McDonough 
Thomas Lotze wrote:
 Chris McDonough wrote:
 
 I'll throw out the obvious...

 Why not subclass Interface in zope.component and make the required API
 additions there?  If it were anybody but us thinking about doing this,
 they'd probably just subclass.
 
 Because then, if you use third-party code that uses
 zope.interface.Interface and other code (third-party or your own) that
 uses the subclassed interfaces, you'll have to deal with both types at the
 same time in your client code. You could use the new API on some
 interfaces but not on others, possibly on the same line of code. How
 readable or maintainable would such code be?

I'm not sure, but if we had it to do all over again, this would be an obvious 
solution.  It would be the work of maybe two days to convert all ZTK packages 
to use a z.c.interface.Interface, and any existing package would need to be 
touched anyway to use .adapt and .utility.  So it bears some weight I think, 
even if it is eventually rejected.

- C

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Zope Tests: 6 OK

2009-12-21 Thread Zope Tests Summarizer 
Summary of messages to the zope-tests list.
Period Sun Dec 20 12:00:00 2009 UTC to Mon Dec 21 12:00:00 2009 UTC.
There were 6 messages: 6 from Zope Tests.


Tests passed OK
---

Subject: OK : Zope-2.10 Python-2.4.6 : Linux
From: Zope Tests
Date: Sun Dec 20 20:37:19 EST 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013233.html

Subject: OK : Zope-2.11 Python-2.4.6 : Linux
From: Zope Tests
Date: Sun Dec 20 20:39:19 EST 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013234.html

Subject: OK : Zope-2.12 Python-2.6.4 : Linux
From: Zope Tests
Date: Sun Dec 20 20:41:20 EST 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013235.html

Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux
From: Zope Tests
Date: Sun Dec 20 20:43:20 EST 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013236.html

Subject: OK : Zope-trunk Python-2.6.4 : Linux
From: Zope Tests
Date: Sun Dec 20 20:45:20 EST 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013237.html

Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux
From: Zope Tests
Date: Sun Dec 20 20:47:20 EST 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013238.html

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zope.testing.doctestunit and BBB

2009-12-21 Thread Marius Gedminas 
On Mon, Dec 21, 2009 at 10:32:42AM +0100, Lennart Regebro wrote:
 On Sun, Dec 20, 2009 at 23:55, Marius Gedminas mar...@gedmin.as wrote:
  I don't know if 'doctestunit' was ever a part of the official
  zope.testing API, I just know that I've learned to use

So, Monday!  I take a deeper look at the codebase, and I see that only
two test files written way back in 2004, in the very oldest corner of
the code used doctestunit in this way.  IOW thanks for the wake-up call,
those two files got promptly fixed.

I'll try collect more info before spewing off next time.

 I've looked through the history of doctestunit, and it seems like it
 once was. This was changed 5 years ago, and doctestunit was left with
 BBB imports without comments and without deprecation.
 
 Then they was removed in a cleanup, as they simply was unused imports.
 
 This probably should be reverted. I'll add them back with
 deprecations, and also deprecate zope.testing.doctest in general.

Can you please make it a PendingDeprecationWarning first?

There were actual bugfixes in zope.testing.doctest that weren't present
in the stdlib's doctest.py (e.g. bin/test --coverage would stop working
if any module imported doctest).  I still have one production instance
running on Python 2.4 (hopefully not for too long), and I'm not sure if
doctest was sufficiently fixed in 2.4.

Marius Gedminas
-- 
http://pov.lt/ -- Zope 3 consulting and development


signature.asc
Description: Digital signature
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zope.testing.doctestunit and BBB

2009-12-21 Thread Marius Gedminas 
On Mon, Dec 21, 2009 at 02:20:54PM +0200, Marius Gedminas wrote:
 On Mon, Dec 21, 2009 at 10:32:42AM +0100, Lennart Regebro wrote:
  On Sun, Dec 20, 2009 at 23:55, Marius Gedminas mar...@gedmin.as wrote:
   I don't know if 'doctestunit' was ever a part of the official
   zope.testing API, I just know that I've learned to use
 
 So, Monday!  I take a deeper look at the codebase, and I see that only
 two test files written way back in 2004, in the very oldest corner of
 the code used doctestunit in this way.  IOW thanks for the wake-up call,
 those two files got promptly fixed.
 
 I'll try collect more info before spewing off next time.

Speaking of more info, looks like this change bit zope.container (trunk as
well as the last stable release 3.10.0) too:

Test-module import failures:

Module: zope.container.tests.test_btree

Traceback (most recent call last):
  File 
/home/mg/src/zope.container/src/zope/container/tests/test_btree.py, line 20, 
in module
from zope.testing.doctestunit import DocTestSuite
ImportError: cannot import name DocTestSuite


Module: zope.container.tests.test_ordered

Traceback (most recent call last):
  File 
/home/mg/src/zope.container/src/zope/container/tests/test_ordered.py, line 
19, in module
from zope.testing.doctestunit import DocTestSuite
ImportError: cannot import name DocTestSuite


Running tests at level 1
Running zope.testing.testrunner.layer.UnitTests tests:
  Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds.
  Running:

  Ran 173 tests with 0 failures and 0 errors in 1.529 seconds.
Tearing down left over layers:
  Tear down zope.testing.testrunner.layer.UnitTests in 0.000 seconds.

Test-modules with import problems:
  zope.container.tests.test_btree
  zope.container.tests.test_ordered


Do we have a buildbot of all latest Zope packages?

Marius Gedminas
-- 
http://pov.lt/ -- Zope 3 consulting and development


signature.asc
Description: Digital signature
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zope.testing.doctestunit and BBB

2009-12-21 Thread Lennart Regebro 
On Mon, Dec 21, 2009 at 13:20, Marius Gedminas mar...@gedmin.as wrote:
 Can you please make it a PendingDeprecationWarning first?

Yeah, I guess, but why? Yes, it had bugfixes, and I have
monkey-patches of doctest in the branch to fix them. But it's not like
they are going to get fixed in 2.4 because we wait with deprecating
the custom doctest. :)

The main reason for it was that it wasn't included in Python 2.3. We
don't want to support Python 2.3 anymore.
-- 
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python-incompatibility.googlecode.com/
+33 661 58 14 64
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] New release needed for z3c.recipe.depgraph

2009-12-21 Thread Fabio Tranchitella 
Hello,

I've just committed a simple patch to allow extras in the eggs option of a
z3c.recipe.depgraph-based recipe. While doing it, I just realized that the
0.4 release has not been uploaded to PyPI, where the most recent version is
0.3.

Package index owners for the package are hannosch, faassen. Can you please
release 0.4 (or better, 0.5 with my fix) to PyPI? My PyPI nickname is
kobold, in case you want me to prepare the release.

Thanks,
Fabio
___
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 release needed for z3c.recipe.depgraph

2009-12-21 Thread Hanno Schlichting 
Hi.

On Mon, Dec 21, 2009 at 9:34 PM, Fabio Tranchitella kob...@kobold.it wrote:
 I've just committed a simple patch to allow extras in the eggs option of a
 z3c.recipe.depgraph-based recipe.

Cool. I properly released 0.5 including your fix :)

Hanno
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zope.testing.doctestunit and BBB

2009-12-21 Thread Marius Gedminas 
On Mon, Dec 21, 2009 at 07:41:24PM +0100, Lennart Regebro wrote:
 On Mon, Dec 21, 2009 at 13:20, Marius Gedminas mar...@gedmin.as wrote:
  Can you please make it a PendingDeprecationWarning first?
 
 Yeah, I guess, but why?

Because I hate it when my code emits DeprecationWarnings, and I wasn't
sure I could throw a switch and migrate to stdlib's doctest.py today
without extensive tests/preparation.

Key word being wasn't.

I migrated my codebase to use stdlib's doctest.py today, and nothing
broke, to my surprise.  Even coverage support continues to work fine (at
some point just having 'import doctest' could make bin/test --coverage
forget about half the code it's seen).

So, I'm fine with a DeprecationWarning.

Marius Gedminas
-- 
http://pov.lt/ -- Zope 3 consulting and development


signature.asc
Description: Digital signature
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zope.testing.doctestunit and BBB

2009-12-21 Thread Lennart Regebro 
On Mon, Dec 21, 2009 at 22:23, Marius Gedminas mar...@gedmin.as wrote:
 On Mon, Dec 21, 2009 at 07:41:24PM +0100, Lennart Regebro wrote:
 On Mon, Dec 21, 2009 at 13:20, Marius Gedminas mar...@gedmin.as wrote:
  Can you please make it a PendingDeprecationWarning first?

 Yeah, I guess, but why?

 Because I hate it when my code emits DeprecationWarnings, and I wasn't
 sure I could throw a switch and migrate to stdlib's doctest.py today
 without extensive tests/preparation.

 Key word being wasn't.

 I migrated my codebase to use stdlib's doctest.py today, and nothing
 broke, to my surprise.  Even coverage support continues to work fine (at
 some point just having 'import doctest' could make bin/test --coverage
 forget about half the code it's seen).

 So, I'm fine with a DeprecationWarning.

Good to hear. I thought they should work, the differences are mostly
in output formatting and such.

I added the imports back, and also some deprecation warnings, although
I'm not sure how to best add them, so I just stuck them in the
modules, so the first import will raise a warning. A new release would
be great, I guess. Christian, what do you say?

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] A summary of Interfaces vs ZCA concepts

2009-12-21 Thread Thomas Lotze 
Chris McDonough wrote:

 Thomas Lotze wrote:
 Because then, if you use third-party code that uses
 zope.interface.Interface and other code (third-party or your own) that
 uses the subclassed interfaces, you'll have to deal with both types at
 the same time in your client code. You could use the new API on some
 interfaces but not on others, possibly on the same line of code. How
 readable or maintainable would such code be?
 
 I'm not sure, but if we had it to do all over again, this would be an
 obvious solution.  It would be the work of maybe two days to convert all
 ZTK packages to use a z.c.interface.Interface, and any existing package
 would need to be touched anyway to use .adapt and .utility.  So it bears
 some weight I think, even if it is eventually rejected.

It does certainly bear some weight as one possibility to be considered.
However, my point wasn't so much about converting a limited existing
amount of code; you're obviously right about having to touch that anyway
in order to use the new methods.

My objection is this: If we go to the trouble of implementing basic
interfaces in zope.interface plus derived ones with component lookup
capabilities in zope.component and keep both around for their respective
reasons of existence, then it is expected that there will be code that
uses both types of interfaces for these very reasons (and maybe other
types which have other added behaviour). Such code would become a lot less
maintainable since you'd never know whether a given interface has a
particular method just because the one next to it does.

OTOH, registering all behaviour an application needs onto the same
interface type doesn't create that problem. As long as you're familiar
with the application at large, you will know for every interface that
occurs in it which methods is has, how they need to be called and what
their semantics are.

Also, subclassing for adding behaviour introduces the typical problems of
hierarchies and tight coupling. This isn't a practical problem as long as
we only ever talk about adaptation as the only use of interfaces, but I'm
trying to discuss interfaces as a language feature with a greater set of
possible use cases.

-- 
Thomas



___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Removing dependency between zope.location and zope.copy

2009-12-21 Thread Fabio Tranchitella 
Hello,

I'm wondering if it would be possible to drop the dependency between
zope.location and zope.copy. It makes sense to me because zope.location
depends on zope.copy only because it registers a LocationCopyHook, not
because it is really using anything from that package.

Attached to this message you can find my (proposed) patch to remove the
dependency making the adapter registration optional, and informing the
developer that zope.copy is needed is he is importing directly the
zope.location.pickling module.

Comments?

Thanks,
Fabio
Index: buildout.cfg
===
--- buildout.cfg	(revisione 106858)
+++ buildout.cfg	(copia locale)
@@ -4,11 +4,11 @@
 
 [test]
 recipe = zc.recipe.testrunner
-eggs = zope.location
+eggs = zope.location [test]
 
 [coverage-test]
 recipe = zc.recipe.testrunner
-eggs = zope.location
+eggs = zope.location [test]
 defaults = ['--coverage', '../../coverage']
 
 [coverage-report]
Index: src/zope/location/configure.zcml
===
--- src/zope/location/configure.zcml	(revisione 106858)
+++ src/zope/location/configure.zcml	(copia locale)
@@ -1,7 +1,9 @@
-configure xmlns=http://namespaces.zope.org/zope;
+configure xmlns=http://namespaces.zope.org/zope;
+   zcml:xmlns=http://namespaces.zope.org/zcml;
 
   adapter factory=.location.LocationProxy /
-  adapter factory=.pickling.LocationCopyHook /
+  adapter zcml:condition=installed zope.copy
+   factory=.pickling.LocationCopyHook /
   adapter factory=.traversing.LocationPhysicallyLocatable /
   adapter factory=.traversing.RootPhysicallyLocatable /
 
Index: src/zope/location/pickling.py
===
--- src/zope/location/pickling.py	(revisione 106858)
+++ src/zope/location/pickling.py	(copia locale)
@@ -18,13 +18,17 @@
 __docformat__ = 'restructuredtext'
 
 from zope.component import adapts
-from zope.copy.interfaces import ICopyHook, ResumeCopy
 from zope.interface import implements
-
 from zope.location.interfaces import ILocation
 from zope.location.location import inside
 
+try:
+from zope.copy.interfaces import ICopyHook, ResumeCopy
+except ImportError:
+raise NotImplementedError(zope.location.pickling is not supported 
+because zope.copy is not available)
 
+
 class LocationCopyHook(object):
 Copy hook to preserve copying referenced objects that are not
 located inside object that's being copied.
Index: setup.py
===
--- setup.py	(revisione 106858)
+++ setup.py	(copia locale)
@@ -56,13 +56,14 @@
   packages=find_packages('src'),
   package_dir = {'': 'src'},
   namespace_packages=['zope',],
+  tests_require=['zope.copy'],
   install_requires=['setuptools',
 'zope.interface',
 'zope.schema=3.5.1dev',
 'zope.component=3.8.0',
 'zope.proxy3.3',
-'zope.copy',
 ],
+  extras_require=dict(test=['zope.copy']),
   include_package_data = True,
   zip_safe = False,
   )
___
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 )