Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/27/2012 06:32 PM, Marius Gedminas wrote:
> I've a comment about this change, which was part of that large "merge
> from launchpad" commit:
>
> ---
> zope.interface/branches/tseaver-better_unittests/src/zope/interface/_zope_interface_coptimizations.c
>
>
>
>
(revision 118418) +++
> zope.interface/branches/tseaver-better_unittests/src/zope/interface/_zope_interface_coptimizations.c
>
>
>
>
(revision 124742) @@ -980,5 +980,11 @@ } else -Py_INCREF(result);
> +{ + if (result == Py_None && default_ != NULL) +{ +
> result = default_; +} + Py_INCREF(result); +}
>
> return result;
>
> It seems to be a bugfix for http://pad.lv/910987 from [1]
>
> [1]
> http://bazaar.launchpad.net/~tseaver/zope.interface/better_unittests/revision/182
>
>
>
>
>
I failed to find any mention of this CHANGES.txt on that branch.
Thanks for the catch. This was indeed a fix for a problem I uncovered
while ensuring that the Python and C implementations passed the same test
suite. I have update the 'CHANGES.txt` file on the branch to indicate
the fix.
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9yeBcACgkQ+gerLs4ltQ6cRQCeI9K1J040qOWRI3OnB6Vu4t3M
DgEAoLSnM4RBc3tcRivZFyWbbVARUpKg
=9SeP
-END PGP SIGNATURE-
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/27/2012 06:21 PM, Marius Gedminas wrote: >> $ bin/python setup.py dev > > Is that different from 'python setup.py develop'? I've never seen 'dev' > before. 'dev' is an alias (defined in 'setup.cfg' for the following:: setup.py develop easy_install zope.interface[testing] >> running develop >> ... >> Finished processing dependencies for zope.interface[testing] >> $ bin/nosetests --with-coverage >> >> ... >> Name Stmts Miss Cover Missing >> >> zope.interface30 0 100% >> zope.interface.adapter 440 0 100% >> zope.interface.advice 69 0 100% >> zope.interface.common 0 0 100% >> zope.interface.common.idatetime 98 0 100% >> zope.interface.common.interfaces 81 0 100% >> zope.interface.common.mapping 32 0 100% >> zope.interface.common.sequence38 0 100% >> zope.interface.declarations 312 0 100% >> zope.interface.document 54 0 100% >> zope.interface.exceptions 21 0 100% >> zope.interface.interface 378 0 100% >> zope.interface.interfaces137 0 100% >> zope.interface.registry 300 0 100% >> zope.interface.ro 25 0 100% >> zope.interface.verify 48 0 100% >> >> TOTAL 2063 0 100% >> -- >> Ran 707 tests in 2.880s > > Ooh, and I also see a tox.ini on that branch! That's extremely welcome! > > (Lately when I had to make some changes to zope.* packages I've been > kind of annoyed about the non-straightforwardness of testing all > supported Python versions. I briefly tried tox, but didn't want to > spend hours figuring out how to make it play nice with buildout.) I still use buildout for complicated "application" installs, but have grown to dislike it for testing "library" code. > Question: does the 100% coverage number mean both C code *and* Python > fallbacks are tested now? They both pass the same suite of tests. I can't guarantee 100% covereage of the C code, but given that it passes the same tests, I'm satisfied. > Question: does 'bin/python setup.py test' work? Yes. I consider that a necessary-but-not-sufficient minium for any library. > It seems to be becoming a sort of a universal standard for "run all the > tests of this Python package please", and is usually not that difficult > to hook up. (If not, I may volunteer to hook it up.) > > Question: can we still use zope.testrunner? You can bootstrap and run the buildout and then run 'bin/test'. > I like some of zope.testrunner's features a lot (like colorization, test > filtering options explicitly by module and by test name). (I may also > volunteer to hook this up, if it's not hooked up.) > >> >> OK >> $ bin/python setup.py docs >> running easy_install >> Searching for zope.interface[docs] >> ... >> Finished processing dependencies for zope.interface[docs] >> $ cd docs >> $ PATH=../bin:$PATH make html >> ... >> build succeeded. >> >> Build finished. The HTML pages are in _build/html. >> -- %< --- > > Ooh, are we going to see zope.interface docs on readthedocs.org? I'm not opposed in principle. :) >> In addition to minimizing "Zope-iness", providing full coverage using >> small, descriptively-named unittests makes the code more maintainable. >> For instance, I expect to build on top of these improved tests as the basis >> for a conversion to a "subset", supporting Python 2.6, 2.7, and 3.x from >> a single codebase, without needing a translator like lib2to3. > > Ooh, nice! > >> I think it will also be easier to improve the docs, now that they no >> longer bear the burden of supplying coverage / regression testing for >> the code. We can remove a bunch of extremely-terse fragments, and have >> the examples which remain fo
Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/27/2012 05:08 AM, Brian Sutherland wrote: > On Mon, Mar 26, 2012 at 05:38:07PM -0400, Tres Seaver wrote: >> In addition to minimizing "Zope-iness", providing full coverage >> using small, descriptively-named unittests makes the code more >> maintainable. For instance, I expect to build on top of these >> improved tests as the basis for a conversion to a "subset", >> supporting Python 2.6, 2.7, and 3.x from a single codebase, without >> needing a translator like lib2to3. >> >> I think it will also be easier to improve the docs, now that they no >> longer bear the burden of supplying coverage / regression testing >> for the code. We can remove a bunch of extremely-terse fragments, >> and have the examples which remain focus more on improving the >> reader's understanding than exercising some corner case. >> >> Unless the consensus is against it, I plan to merge this branch to >> the trunk early next week. > > This sounds great, I think it's exactly the right way to go. It's > just a LOT of work, a BIG thanks for taking it on! Thanks for the support! Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9yQA8ACgkQ+gerLs4ltQ40LwCggtNkxJxKGsazi76KBz3IMM9c eUQAnj5aM1M1gZnryHwpjKjSswn8tzX2 =Rkao -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface
On Mon, Mar 26, 2012 at 05:38:07PM -0400, Tres Seaver wrote:
> I've (finally!) finished my work to get zope.interface to 100% unit test
> coverage without relying on doctests:
>
> http://svn.zope.org/zope.interface/branches/tseaver-better_unittests/
>
> The work is outlined in this document on the branch:
>
>
> http://svn.zope.org/zope.interface/branches/tseaver-better_unittests/README-better_unittest.txt?rev=124744&view=auto
I've a comment about this change, which was part of that large "merge
from launchpad" commit:
---
zope.interface/branches/tseaver-better_unittests/src/zope/interface/_zope_interface_coptimizations.c
(revision 118418)
+++
zope.interface/branches/tseaver-better_unittests/src/zope/interface/_zope_interface_coptimizations.c
(revision 124742)
@@ -980,5 +980,11 @@
}
else
-Py_INCREF(result);
+{
+ if (result == Py_None && default_ != NULL)
+{
+ result = default_;
+}
+ Py_INCREF(result);
+}
return result;
It seems to be a bugfix for http://pad.lv/910987 from [1]
[1]
http://bazaar.launchpad.net/~tseaver/zope.interface/better_unittests/revision/182
I failed to find any mention of this CHANGES.txt on that branch.
Cheers!
Marius Gedminas
--
http://pov.lt/ -- Zope 3/BlueBream 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] Merge proposal: tseaver-better_unittests branch of zope.interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/27/2012 05:08 AM, Brian Sutherland wrote: > On Mon, Mar 26, 2012 at 05:38:07PM -0400, Tres Seaver wrote: >> In addition to minimizing "Zope-iness", providing full coverage >> using small, descriptively-named unittests makes the code more >> maintainable. For instance, I expect to build on top of these >> improved tests as the basis for a conversion to a "subset", >> supporting Python 2.6, 2.7, and 3.x from a single codebase, without >> needing a translator like lib2to3. >> >> I think it will also be easier to improve the docs, now that they >> no longer bear the burden of supplying coverage / regression testing >> for the code. We can remove a bunch of extremely-terse fragments, >> and have the examples which remain focus more on improving the >> reader's understanding than exercising some corner case. >> >> Unless the consensus is against it, I plan to merge this branch to >> the trunk early next week. > > This sounds great, I think it's exactly the right way to go. It's just > a LOT of work, a BIG thanks for taking it on! Thanks for the support! Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9yP+IACgkQ+gerLs4ltQ5aawCfY5GhVswjgbDYTuVeZc0NyukP wPoAoKMPxLs034DbJmMg6/mwRqxBlR98 =ZEWK -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface
On Mon, Mar 26, 2012 at 05:38:07PM -0400, Tres Seaver wrote: > I've (finally!) finished my work to get zope.interface to 100% unit test > coverage without relying on doctests: > > http://svn.zope.org/zope.interface/branches/tseaver-better_unittests/ Yay! > The work is outlined in this document on the branch: > > http://svn.zope.org/zope.interface/branches/tseaver-better_unittests/README-better_unittest.txt?rev=124744&view=auto > > For those who are into sausage factories, the bulk of the work is > available on Launchpad: > > https://code.launchpad.net/~tseaver/zope.interface/better_unittests > > The branch makes many fewer "Zope-y" assumptions about how it is > developed. In particular, in a fresh checkout, you can run the tests > and build the docs with widely-used 3rd-party tools, without needing > to set up a buildout:: > > -- %< --- > $ svn co $ZSVN/zope.interface/branches/tseaver-better_unittests > ... > U tseaver-better_unittests > Checked out revision 124746. > $ /opt/Python-2.7.2/bin/virtualenv . > New python executable in ./bin/python > Installing setuptoolsdone. > Installing pip...done. > $ bin/python setup.py dev Is that different from 'python setup.py develop'? I've never seen 'dev' before. > running develop > ... > Finished processing dependencies for zope.interface[testing] > $ bin/nosetests --with-coverage > > ... > Name Stmts Miss Cover Missing > > zope.interface30 0 100% > zope.interface.adapter 440 0 100% > zope.interface.advice 69 0 100% > zope.interface.common 0 0 100% > zope.interface.common.idatetime 98 0 100% > zope.interface.common.interfaces 81 0 100% > zope.interface.common.mapping 32 0 100% > zope.interface.common.sequence38 0 100% > zope.interface.declarations 312 0 100% > zope.interface.document 54 0 100% > zope.interface.exceptions 21 0 100% > zope.interface.interface 378 0 100% > zope.interface.interfaces137 0 100% > zope.interface.registry 300 0 100% > zope.interface.ro 25 0 100% > zope.interface.verify 48 0 100% > > TOTAL 2063 0 100% > -- > Ran 707 tests in 2.880s Ooh, and I also see a tox.ini on that branch! That's extremely welcome! (Lately when I had to make some changes to zope.* packages I've been kind of annoyed about the non-straightforwardness of testing all supported Python versions. I briefly tried tox, but didn't want to spend hours figuring out how to make it play nice with buildout.) Question: does the 100% coverage number mean both C code *and* Python fallbacks are tested now? Question: does 'bin/python setup.py test' work? It seems to be becoming a sort of a universal standard for "run all the tests of this Python package please", and is usually not that difficult to hook up. (If not, I may volunteer to hook it up.) Question: can we still use zope.testrunner? I like some of zope.testrunner's features a lot (like colorization, test filtering options explicitly by module and by test name). (I may also volunteer to hook this up, if it's not hooked up.) > > OK > $ bin/python setup.py docs > running easy_install > Searching for zope.interface[docs] > ... > Finished processing dependencies for zope.interface[docs] > $ cd docs > $ PATH=../bin:$PATH make html > ... > build succeeded. > > Build finished. The HTML pages are in _build/html. > -- %< --- Ooh, are we going to see zope.interface docs on readthedocs.org? > In addition to minimizing "Zope-iness", providing full coverage using > small, descriptively-named unittests makes the code more maintainable. > For instance
Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/27/2012 02:25 AM, Wolfgang Schnerring wrote:
> * Tres Seaver [2012-03-26 23:38]:
>> I've (finally!) finished my work to get zope.interface to 100% unit
>> test coverage without relying on doctests:
>
> That's an impressive feat, congratulations!
Thank you!
>> In addition to minimizing "Zope-iness", providing full coverage
>> using small, descriptively-named unittests makes the code more
>> maintainable. For instance, I expect to build on top of these
>> improved tests as the basis for a conversion to a "subset",
>> supporting Python 2.6, 2.7, and 3.x from a single codebase, without
>> needing a translator like lib2to3.
>>
>> I think it will also be easier to improve the docs, now that they
>> no longer bear the burden of supplying coverage / regression testing
>> for the code. We can remove a bunch of extremely-terse fragments,
>> and have the examples which remain focus more on improving the
>> reader's understanding than exercising some corner case.
>
> I haven't had time yet to review this in detail, but this is most
> definitely the right direction: separate tests from documentation,
> make the tests expressive and the documentation clear. Wonderful!
> (I've I get some 'round toits, I'd much like to look through this;
> I'll let you know if I find anything.)
Great, thanks!
>> Unless the consensus is against it, I plan to merge this branch to
>> the trunk early next week.
>
> +1, please do.
>
>> The branch makes many fewer "Zope-y" assumptions about how it is
>> developed. In particular, in a fresh checkout, you can run the
>> tests and build the docs with widely-used 3rd-party tools, without
>> needing to set up a buildout::
>
> Since I've thinking along these lines recently ("why do I need
> buildout if all I want is a testrunner?"), I'm curious as to how this
> works, especially - Where does bin/nosetests come from? - Where does
> "setup.py docs" come from?
The 'docs' and 'dev' aliases are defined in setup.cfg::
$ tail -n -3 setup.cfg
[aliases]
dev = develop easy_install zope.interface[testing]
docs = easy_install zope.interface[docs]
and their extras_require in setup.py::
$ egrep -B 2 "(testing_extras|'docs')" setup.py
features = {'codeoptimization': codeoptimization}
tests_require = ['zope.event']
testing_extras = tests_require + ['nose', 'coverage']
--
tests_require = tests_require,
install_requires = ['setuptools'],
extras_require={'docs': ['Sphinx'],
'test': tests_require,
'testing': testing_extras,
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9xr0wACgkQ+gerLs4ltQ4ihACg22pNtSDSrBpJ6jHEijmqJKc5
ihcAnAyjrukF6ukG8XVuyZREup89q1nr
=v9nN
-END PGP SIGNATURE-
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface
On Mon, Mar 26, 2012 at 05:38:07PM -0400, Tres Seaver wrote: > In addition to minimizing "Zope-iness", providing full coverage using > small, descriptively-named unittests makes the code more maintainable. > For instance, I expect to build on top of these improved tests as the basis > for a conversion to a "subset", supporting Python 2.6, 2.7, and 3.x from > a single codebase, without needing a translator like lib2to3. > > I think it will also be easier to improve the docs, now that they no > longer bear the burden of supplying coverage / regression testing for > the code. We can remove a bunch of extremely-terse fragments, and have > the examples which remain focus more on improving the reader's > understanding than exercising some corner case. > > Unless the consensus is against it, I plan to merge this branch to the > trunk early next week. This sounds great, I think it's exactly the right way to go. It's just a LOT of work, a BIG thanks for taking it on! -- Brian Sutherland ___ 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] Merge proposal: tseaver-better_unittests branch of zope.interface
* Tres Seaver [2012-03-26 23:38]:
> I've (finally!) finished my work to get zope.interface to 100% unit test
> coverage without relying on doctests:
That's an impressive feat, congratulations!
> In addition to minimizing "Zope-iness", providing full coverage using
> small, descriptively-named unittests makes the code more maintainable.
> For instance, I expect to build on top of these improved tests as the basis
> for a conversion to a "subset", supporting Python 2.6, 2.7, and 3.x from
> a single codebase, without needing a translator like lib2to3.
>
> I think it will also be easier to improve the docs, now that they no
> longer bear the burden of supplying coverage / regression testing for
> the code. We can remove a bunch of extremely-terse fragments, and have
> the examples which remain focus more on improving the reader's
> understanding than exercising some corner case.
I haven't had time yet to review this in detail, but this is most
definitely the right direction: separate tests from documentation, make
the tests expressive and the documentation clear. Wonderful!
(I've I get some 'round toits, I'd much like to look through this; I'll
let you know if I find anything.)
> Unless the consensus is against it, I plan to merge this branch to the
> trunk early next week.
+1, please do.
> The branch makes many fewer "Zope-y" assumptions about how it is
> developed. In particular, in a fresh checkout, you can run the tests
> and build the docs with widely-used 3rd-party tools, without needing
> to set up a buildout::
Since I've thinking along these lines recently ("why do I need buildout
if all I want is a testrunner?"), I'm curious as to how this works,
especially
- Where does bin/nosetests come from?
- Where does "setup.py docs" come from?
Wolfgang
___
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 )
