Hi,
On 04/17/2010 06:34 AM, Martin Aspeli wrote:
Hi Lennart co,
On 17 April 2010 02:38, Lennart Regebrorege...@gmail.com wrote:
On Fri, Apr 16, 2010 at 19:53, Jonathan Langej...@mumak.net wrote:
As the author of one of those other testrunners, I can tell you that
if you do this you'll
On Tue, Apr 20, 2010 at 12:09 PM, Christian Theune c...@gocept.com wrote:
Minor note: zope.testing *promotes* layers the wrong way and
zope.app.testing definitely implements them the wrong way.
That's prety vague. Could you say specifically in what ways
zope.testing promotes layers the wrong
On 04/20/2010 08:44 PM, Jim Fulton wrote:
On Tue, Apr 20, 2010 at 12:09 PM, Christian Theunec...@gocept.com wrote:
Minor note: zope.testing *promotes* layers the wrong way and
zope.app.testing definitely implements them the wrong way.
That's prety vague. Could you say specifically in what
On Tue, Apr 20, 2010 at 2:58 PM, Christian Theune c...@gocept.com 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
On 04/20/2010 09:04 PM, Fred Drake wrote:
On Tue, Apr 20, 2010 at 2:58 PM, Christian Theunec...@gocept.com 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
On Tue, Apr 20, 2010 at 3:04 PM, Fred Drake fdr...@gmail.com wrote:
On Tue, Apr 20, 2010 at 2:58 PM, Christian Theune c...@gocept.com wrote:
zope.testing uses the attribute '__bases__' to store the information what
the base layers are. __*__ are supposedly Python internal attributes.
On 04/20/2010 09:24 PM, Jim Fulton wrote:
On Tue, Apr 20, 2010 at 3:04 PM, Fred Drakefdr...@gmail.com wrote:
On Tue, Apr 20, 2010 at 2:58 PM, Christian Theunec...@gocept.com wrote:
zope.testing uses the attribute '__bases__' to store the information what
the base layers are. __*__ are
On Tue, Apr 20, 2010 at 3:47 PM, Christian Theune c...@gocept.com 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
On 04/20/2010 10:05 PM, Fred Drake wrote:
On Tue, Apr 20, 2010 at 3:47 PM, Christian Theunec...@gocept.com 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__
On Tue, Apr 20, 2010 at 4:09 PM, Christian Theune c...@gocept.com 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.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
On Tue, Apr 20, 2010 at 4:05 PM, Fred Drake fdr...@gmail.com wrote:
...
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
On 04/20/2010 10:48 PM, Jim Fulton wrote:
On Tue, Apr 20, 2010 at 4:05 PM, Fred Drakefdr...@gmail.com wrote:
...
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
Hi Christian,
On 21 April 2010 02:58, Christian Theune c...@gocept.com wrote:
On 04/20/2010 08:44 PM, Jim Fulton wrote:
On Tue, Apr 20, 2010 at 12:09 PM, Christian Theunec...@gocept.com wrote:
Minor note: zope.testing *promotes* layers the wrong way and
zope.app.testing definitely
Tres Seaver a écrit :
So far the main circularity was that everything depended on
zope.testing as a testrunner, zc.buildout for making the development
environment, and zope.testing obviously depended on zope.interface
etc. I solved that by also adding support for setuptools/distributes
On Sun, Apr 18, 2010 at 10:37, Christophe Combelles cc...@free.fr wrote:
Depending on setuptools for tests in another evil thing. We should not assume
a
*setup* tool to be a testrunner, and we should not depend on the behaviour of
setuptools to write tests.
I'm not sure what you mean there,
On 4/18/10 10:37 , Christophe Combelles wrote:
Tres Seaver a écrit :
So far the main circularity was that everything depended on
zope.testing as a testrunner, zc.buildout for making the development
environment, and zope.testing obviously depended on zope.interface
etc. I solved that by also
Lennart Regebro a écrit :
On Sun, Apr 18, 2010 at 10:37, Christophe Combelles cc...@free.fr wrote:
Depending on setuptools for tests in another evil thing. We should not
assume a
*setup* tool to be a testrunner, and we should not depend on the behaviour of
setuptools to write tests.
I'm
On Sun, Apr 18, 2010 at 11:35, Christophe Combelles cc...@free.fr wrote:
ok, not a lot, there is currently one single particular behaviour, which is
adding tests from the result of the additional_tests function in a module.
That probably won't hurt.
Yeah, setuptools test discovery isn't very
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christophe Combelles wrote:
Tres Seaver a écrit :
So far the main circularity was that everything depended on
zope.testing as a testrunner, zc.buildout for making the development
environment, and zope.testing obviously depended on zope.interface
On Sat, Apr 17, 2010 at 06:34, Martin Aspeli optilude+li...@gmail.com wrote:
Hi Lennart co,
On 17 April 2010 02:38, Lennart Regebro rege...@gmail.com wrote:
On Fri, Apr 16, 2010 at 19:53, Jonathan Lange j...@mumak.net wrote:
As the author of one of those other testrunners, I can tell you
This is to a large part an angry rant. Sorry for that.
In my effort to port zope.component to Python 3 I constantly encounter
one problem that is very hard to solve: Circular dependencies. It's
hard to port module A, when running the tests require module B to be
ported, and module B depends on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lennart Regebro wrote:
This is to a large part an angry rant. Sorry for that.
In my effort to port zope.component to Python 3 I constantly encounter
one problem that is very hard to solve: Circular dependencies. It's
hard to port module A, when
On Apr 16, 2010, at 1:35 PM, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lennart Regebro wrote:
...
So, with that in mind I today went on to zc.buildout, trying to port
it to Python 3 by ripping out any usage of zope.testing. Also, the
standard development mode for
On Fri, Apr 16, 2010 at 6:05 PM, Lennart Regebro rege...@gmail.com wrote:
...
== Suggestion 1 ==
I think we should deprecate zope.testing. Completely. There has been
some discussion about deprecating it for something else, but I think
we should just deprecate it. Just say Don't use
On Fri, Apr 16, 2010 at 19:53, Jonathan Lange j...@mumak.net wrote:
As the author of one of those other testrunners, I can tell you that
if you do this you'll find that your number one biggest problem is
getting layers to work.
Ah, right, layers are in zope.testing too. To actually get
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lennart Regebro wrote:
On Fri, Apr 16, 2010 at 19:35, Tres Seaver tsea...@palladion.com wrote:
== Suggestion 1 ==
I think we should deprecate zope.testing. Completely. There has been
some discussion about deprecating it for something else, but I
On Fri, Apr 16, 2010 at 20:40, Tres Seaver tsea...@palladion.com wrote:
How about we move out the testrunner (including updating
zc.recipe.testrunner), clean out any remaining cruft, and release a new
major version containing only bits used in real-world tests?
Sounds like a good plan to me.
On Fri, Apr 16, 2010 at 2:40 PM, Tres Seaver tsea...@palladion.com 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
On Fri, Apr 16, 2010 at 20:43, Lennart Regebro rege...@gmail.com wrote:
On Fri, Apr 16, 2010 at 20:40, Tres Seaver tsea...@palladion.com wrote:
How about we move out the testrunner (including updating
zc.recipe.testrunner), clean out any remaining cruft, and release a new
major version
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fred Drake wrote:
On Fri, Apr 16, 2010 at 2:40 PM, Tres Seaver tsea...@palladion.com wrote:
:mod:`zope.testing.formparser`
Parses rendered HTML forms back to datastructures. Maybe useful
in tests which consume rendered output.
No ZTK
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lennart Regebro wrote:
On Fri, Apr 16, 2010 at 20:43, Lennart Regebro rege...@gmail.com wrote:
On Fri, Apr 16, 2010 at 20:40, Tres Seaver tsea...@palladion.com wrote:
How about we move out the testrunner (including updating
zc.recipe.testrunner),
On Fri, Apr 16, 2010 at 22:44, Tres Seaver tsea...@palladion.com wrote:
We will have factored the reusable bits (which we know get re-used)
into a smaller, cleaner package, which should (I hope) be easier to port.
Other packages which depend on only those bits should be more easily
testable
Hi Lennart co,
On 17 April 2010 02:38, Lennart Regebro rege...@gmail.com wrote:
On Fri, Apr 16, 2010 at 19:53, Jonathan Lange j...@mumak.net wrote:
As the author of one of those other testrunners, I can tell you that
if you do this you'll find that your number one biggest problem is
getting
33 matches
Mail list logo
