Re: [Python-Dev] Python Language Summit at PyCon: Agenda
Le Mon, 4 Mar 2013 19:46:07 +1300, Robert Collins robe...@robertcollins.net a écrit : On 4 March 2013 19:40, Nick Coghlan ncogh...@gmail.com wrote: Your feedback on http://bugs.python.org/issue16997 would be greatly appreciated. Done directly to Antoine on IRC the other day in a conversation with him and Michael about the compatability impact of subtests. Happy to do a full code review if that would be useful. Indeed and some of the changes in the latest patch stem from that conversation. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Disabling string interning for null and single-char causes segfaults
On 02.03.13 22:32, Terry Reedy wrote: I am just curious: does 3.3 still intern (some) unicode chars? Did the 256 interned bytes of 2.x carry over to 3.x? Yes, Python 3 interns an empty string and first 256 Unicode characters. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Disabling string interning for null and single-char causes segfaults
On 01.03.13 17:24, Stefan Bucur wrote: Before digging deeper into the issue, I wanted to ask here if there are any implicit assumptions about string identity and interning throughout the interpreter implementation. For instance, are two single-char strings having the same content supposed to be identical objects? I think this is not a bug if the code relies on the fact that an empty string is a singleton. This obviously is an immutable object and there is no public method to create different empty string. But a user can create different 1-character strings with same value (first create uninitialized a 1-character string and than fill a content). If some code fails when none of 1-character strings are interned, this obviously is a bug. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On Mar 04, 2013, at 07:26 PM, Robert Collins wrote: It is of course possible for subunit and related tools to run their own implementation, but it seems ideal to me to have a common API which regular unittest, nose, py.test and others can all agree on and use : better reuse for pretty printers, GUI displays and the like depend on some common API. And One True Way of invoking and/or discovering how to invoke, a package's test suite. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Introducing Electronic Contributor Agreements
The full announcement is at http://blog.python.org/2013/03/introducing-electronic-contributor.html, but a summary follows. We've now moved to an electronic Contributor License Agreement form at http://www.python.org/psf/contrib/contrib-form/ which will hopefully ease the signing and sending of forms for our potential contributors. The form shows the required fields whether you're signing as an individual or a representative of an organization, and removes the need to print, scan, fax, etc. When a new contributor fills in the form, they are emailed a copy of the form and asked to confirm the email address that they used (and received that copy at). Upon confirming, the signed form is sent to the PSF Administrator and filed away. The signature can either be generated from your typed name, or you can draw or upload your actual written signature if you choose. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Introducing Electronic Contributor Agreements
On Mon, Mar 4, 2013 at 11:30 AM, Brian Curtin br...@python.org wrote: The full announcement is at http://blog.python.org/2013/03/introducing-electronic-contributor.html, but a summary follows. We've now moved to an electronic Contributor License Agreement form at http://www.python.org/psf/contrib/contrib-form/ which will hopefully ease the signing and sending of forms for our potential contributors. The form shows the required fields whether you're signing as an individual or a representative of an organization, and removes the need to print, scan, fax, etc. When a new contributor fills in the form, they are emailed a copy of the form and asked to confirm the email address that they used (and received that copy at). Upon confirming, the signed form is sent to the PSF Administrator and filed away. The signature can either be generated from your typed name, or you can draw or upload your actual written signature if you choose. With this in place I would like to propose that all patches submitted to bugs.python.org must come from someone who has signed the CLA before we consider committing it (if you want to be truly paranoid we could say that we won't even look at the code w/o a CLA). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 11:29 AM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:26 PM, Robert Collins wrote: It is of course possible for subunit and related tools to run their own implementation, but it seems ideal to me to have a common API which regular unittest, nose, py.test and others can all agree on and use : better reuse for pretty printers, GUI displays and the like depend on some common API. And One True Way of invoking and/or discovering how to invoke, a package's test suite. How does unittest's test discovery not solve that? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 4:34 PM, Brett Cannon br...@python.org wrote: On Mon, Mar 4, 2013 at 11:29 AM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:26 PM, Robert Collins wrote: It is of course possible for subunit and related tools to run their own implementation, but it seems ideal to me to have a common API which regular unittest, nose, py.test and others can all agree on and use : better reuse for pretty printers, GUI displays and the like depend on some common API. And One True Way of invoking and/or discovering how to invoke, a package's test suite. How does unittest's test discovery not solve that? It is not always obvious how to test a package when one is not familiar with it. Are the tests in pkgname/tests or tests or ... ? In the scientific community, we have used the convention of making the test suite available at runtime with pkgname.tests(). David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 11:44 AM, David Cournapeau courn...@gmail.comwrote: On Mon, Mar 4, 2013 at 4:34 PM, Brett Cannon br...@python.org wrote: On Mon, Mar 4, 2013 at 11:29 AM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:26 PM, Robert Collins wrote: It is of course possible for subunit and related tools to run their own implementation, but it seems ideal to me to have a common API which regular unittest, nose, py.test and others can all agree on and use : better reuse for pretty printers, GUI displays and the like depend on some common API. And One True Way of invoking and/or discovering how to invoke, a package's test suite. How does unittest's test discovery not solve that? It is not always obvious how to test a package when one is not familiar with it. Are the tests in pkgname/tests or tests or ... ? I would argue that's a packaging problem and not a testing infrastructure in the stdlib problem. If we want to standardize on always having the tests in a 'tests' sub-package that's fine, but I don't see unittest or subtest directly controlling that short of some registration hook that has to be called to declare where the tests are. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On Mar 04, 2013, at 11:34 AM, Brett Cannon wrote: And One True Way of invoking and/or discovering how to invoke, a package's test suite. How does unittest's test discovery not solve that? I should have added from the command line. E.g. is it: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Introducing Electronic Contributor Agreements
On Mon, Mar 4, 2013 at 10:30 AM, Brian Curtin br...@python.org wrote: The full announcement is at http://blog.python.org/2013/03/introducing-electronic-contributor.html, but a summary follows. ... Brian, Do you want old-timers like me who have a wet-signed fax gathering dust in a box at PSF World Headquarters to execute the electronic contributor agreement? While not strictly necessary, I suspect it might be nice for you to have all agreements in a common form. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Introducing Electronic Contributor Agreements
On Mon, Mar 4, 2013 at 11:02 AM, Skip Montanaro s...@pobox.com wrote: On Mon, Mar 4, 2013 at 10:30 AM, Brian Curtin br...@python.org wrote: The full announcement is at http://blog.python.org/2013/03/introducing-electronic-contributor.html, but a summary follows. ... Brian, Do you want old-timers like me who have a wet-signed fax gathering dust in a box at PSF World Headquarters to execute the electronic contributor agreement? While not strictly necessary, I suspect it might be nice for you to have all agreements in a common form. I'll check on that, but I don't think it's necessary since the gathered data is no different. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On Mon, 4 Mar 2013 11:51:04 -0500 Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 11:34 AM, Brett Cannon wrote: And One True Way of invoking and/or discovering how to invoke, a package's test suite. How does unittest's test discovery not solve that? I should have added from the command line. E.g. is it: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. I hope we can have a pytest utility that does the right thing in 3.4 :-) Typing python -m unittest discover is too cumbersome. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Disabling string interning for null and single-char causes segfaults
2013/3/4 Serhiy Storchaka storch...@gmail.com
On 01.03.13 17:24, Stefan Bucur wrote:
Before digging deeper into the issue, I wanted to ask here if there are
any implicit assumptions about string identity and interning throughout
the interpreter implementation. For instance, are two single-char
strings having the same content supposed to be identical objects?
I think this is not a bug if the code relies on the fact that an empty
string is a singleton. This obviously is an immutable object and there is
no public method to create different empty string.
Really?
x = u'\xe9'.encode('ascii', 'ignore')
x == '', x is ''
(True, False)
--
Amaury Forgeot d'Arc
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 8:41 PM, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 4 Mar 2013 11:51:04 -0500 Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 11:34 AM, Brett Cannon wrote: And One True Way of invoking and/or discovering how to invoke, a package's test suite. How does unittest's test discovery not solve that? I should have added from the command line. E.g. is it: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. I hope we can have a pytest utility that does the right thing in 3.4 :-) Typing python -m unittest discover is too cumbersome. Regards Antoine. Please pick a different name though, pytest is already widely used. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Disabling string interning for null and single-char causes segfaults
On Mon, Mar 4, 2013 at 11:06 AM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
2013/3/4 Serhiy Storchaka storch...@gmail.com
On 01.03.13 17:24, Stefan Bucur wrote:
Before digging deeper into the issue, I wanted to ask here if there are
any implicit assumptions about string identity and interning throughout
the interpreter implementation. For instance, are two single-char
strings having the same content supposed to be identical objects?
I think this is not a bug if the code relies on the fact that an empty
string is a singleton. This obviously is an immutable object and there is no
public method to create different empty string.
Really?
x = u'\xe9'.encode('ascii', 'ignore')
x == '', x is ''
(True, False)
Code that relies on this is incorrect (the language doesn't guarantee
interning) but nevertheless given the intention of the implementation,
that behavior of encode() is also a bug.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. I hope we can have a pytest utility that does the right thing in 3.4 :-) Typing python -m unittest discover is too cumbersome. Where is this work being done (e.g. is there a PEP)? One thing to keep in mind is how to invoke this on a system with multiple versions of Python available. For example, in Debian, a decision was recently made to drop all the nosetests-X.Y scripts from /usr/bin[1]. This makes sense when you think about having at least two major versions of Python (2.x and 3.x) and maybe up to four (2.6, 2.7, 3.2, 3.3), *plus* debug versions of each. Add to that, we don't actually know at package build time which versions of Python you might have installed on your system. A suggestion was made to provide a main entry point so that `pythonX.Y -m nose` would work, which makes sense to me and was adopted by the nose-devs[2]. So while a top level `pytest` command may make sense, it also might not ;). While PEP 426 has a way to declare test dependencies (a good thing), it seems to have no way to declare how to actually run the tests. Cheers, -Barry [1] Start of thread: http://comments.gmane.org/gmane.linux.debian.devel.python/8572 [2] https://github.com/nose-devs/nose/issues/634 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Disabling string interning for null and single-char causes segfaults
2013/3/4 Guido van Rossum gu...@python.org
x = u'\xe9'.encode('ascii', 'ignore')
x == '', x is ''
(True, False)
Code that relies on this is incorrect (the language doesn't guarantee
interning) but nevertheless given the intention of the implementation,
that behavior of encode() is also a bug.
The example above is obviously from python2.7; there is a similar example
with python3.2:
x = b'\xe9\xe9'.decode('ascii', 'ignore')
x == '', x is ''
(True, False)
...but this bug has been fixed in 3.3: PyUnicode_Resize() always returns
the unicode_empty singleton.
--
Amaury Forgeot d'Arc
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 9:14 PM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. I hope we can have a pytest utility that does the right thing in 3.4 :-) Typing python -m unittest discover is too cumbersome. Where is this work being done (e.g. is there a PEP)? There is an open issue on the tracker: http://bugs.python.org/issue14266 --Berker ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Introducing Electronic Contributor Agreements
On Tue, Mar 5, 2013 at 3:30 AM, Brian Curtin br...@python.org wrote: The full announcement is at http://blog.python.org/2013/03/introducing-electronic-contributor.html, but a summary follows. We've now moved to an electronic Contributor License Agreement form at http://www.python.org/psf/contrib/contrib-form/ which will hopefully ease the signing and sending of forms for our potential contributors. The form shows the required fields whether you're signing as an individual or a representative of an organization, and removes the need to print, scan, fax, etc. When a new contributor fills in the form, they are emailed a copy of the form and asked to confirm the email address that they used (and received that copy at). Upon confirming, the signed form is sent to the PSF Administrator and filed away. The signature can either be generated from your typed name, or you can draw or upload your actual written signature if you choose. I had been procrastinating on filling in the paper version, but having this means no excuse. The process was very simple and straight forward. (The only difficult part was actually working out my python bugs username). Thanks for taking the administrative effort to get this all in place. Cheers, Benno ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On 5 March 2013 05:34, Brett Cannon br...@python.org wrote: On Mon, Mar 4, 2013 at 11:29 AM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:26 PM, Robert Collins wrote: It is of course possible for subunit and related tools to run their own implementation, but it seems ideal to me to have a common API which regular unittest, nose, py.test and others can all agree on and use : better reuse for pretty printers, GUI displays and the like depend on some common API. And One True Way of invoking and/or discovering how to invoke, a package's test suite. How does unittest's test discovery not solve that? Three reasons a) There are some bugs (all filed I think) - I intend to hack on these in the near future - that prevent discovery working at all for some use cases. b) discovery requires magic parameters that are project specific (e.g. is it 'discover .' or 'discover . lib' to run it). This is arguably a setup.py/packaging entrypoint issue. c) Test suites written for e.g. Twisted, or nose, or other non-stdunit-runner-compatible test runners will fail to execute even when discovered correctly. There are ways to solve this without addressing a/b/c - just defining a standard command to run that signals success/failure with it's exit code. Packages can export a particular flavour of that in their setup.py if they have exceptional needs, and do nothing in the common case. That doesn't solve 'how to introspect a package test suite' but for distro packagers - and large scale CI integration - that doesn't matter. For instance testrepository offers a setuptools extension to let it be used trivially, I believe nose does something similar. Having something that would let *any* test suite spit out folk's favourite test protocol de jour would be brilliant of course :). [junit-xml, subunit, TAP, ...] -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 2:26 PM, Berker Peksağ berker.pek...@gmail.com wrote: On Mon, Mar 4, 2013 at 9:14 PM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. I hope we can have a pytest utility that does the right thing in 3.4 :-) Typing python -m unittest discover is too cumbersome. Where is this work being done (e.g. is there a PEP)? There is an open issue on the tracker: http://bugs.python.org/issue14266 --Berker setup.py's setup(test_suite=x)... not sure if this is a distutils or setuptools feature. PEP 426 has an extension mechanism that could do the job. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On 5 March 2013 05:51, Barry Warsaw ba...@python.org wrote: I should have added from the command line. E.g. is it: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y $ testr run :) Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. pimping own horse If there is a .testr.conf you can run 'testr init; testr run'. Thats the defined entry point for testr, and .testr.conf can specify running make, or setup.py build or whatever else is needed to run tests. /pimp I would love to see a declaritive interface so that you can tell that is what you should run. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On Mar 04, 2013, at 03:02 PM, Daniel Holth wrote: setup.py's setup(test_suite=x)... not sure if this is a distutils or setuptools feature. PEP 426 has an extension mechanism that could do the job. Shouldn't testing be a first order feature? -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 3:14 PM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 03:02 PM, Daniel Holth wrote: setup.py's setup(test_suite=x)... not sure if this is a distutils or setuptools feature. PEP 426 has an extension mechanism that could do the job. Shouldn't testing be a first order feature? Unfortunately there are so many potential first-order features that we've had to leave some out in order to save time. How to run the tests is not something that you need to know when searching PyPI for a distribution and its dependencies. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On Mar 04, 2013, at 03:40 PM, Daniel Holth wrote: On Mon, Mar 4, 2013 at 3:14 PM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 03:02 PM, Daniel Holth wrote: setup.py's setup(test_suite=x)... not sure if this is a distutils or setuptools feature. PEP 426 has an extension mechanism that could do the job. Shouldn't testing be a first order feature? Unfortunately there are so many potential first-order features that we've had to leave some out in order to save time. How to run the tests is not something that you need to know when searching PyPI for a distribution and its dependencies. Although has unittests that I can run might be a deciding factor of which of the many implementations of a particular feature you might choose. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Introducing Electronic Contributor Agreements
On 3/4/2013 11:36 AM, Brett Cannon wrote: On Mon, Mar 4, 2013 at 11:30 AM, Brian Curtin br...@python.org mailto:br...@python.org wrote: The full announcement is at http://blog.python.org/2013/03/introducing-electronic-contributor.html, but a summary follows. We've now moved to an electronic Contributor License Agreement form at http://www.python.org/psf/contrib/contrib-form/ which will hopefully ease the signing and sending of forms for our potential contributors. The form shows the required fields whether you're signing as an individual or a representative of an organization, and removes the need to print, scan, fax, etc. When a new contributor fills in the form, they are emailed a copy of the form and asked to confirm the email address that they used (and received that copy at). Upon confirming, the signed form is sent to the PSF Administrator and filed away. The signature can either be generated from your typed name, or you can draw or upload your actual written signature if you choose. With this in place I would like to propose that all patches submitted to bugs.python.org http://bugs.python.org must come from someone who has signed the CLA before we consider committing it (if you want to be truly paranoid we could say that we won't even look at the code w/o a CLA). Either policy could be facilitated by tracker changes. In order to see the file upload box, one must login and the tracker knows who has a CLA on file (as indicated by a * suffix on the name). If a file is uploaded by someone without, a box could popup with the link to the e-form and a message that a CLA is required. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Disabling string interning for null and single-char causes segfaults
Hi,
2013/3/4 Amaury Forgeot d'Arc amaur...@gmail.com:
The example above is obviously from python2.7; there is a similar example
with python3.2:
x = b'\xe9\xe9'.decode('ascii', 'ignore')
x == '', x is ''
(True, False)
...but this bug has been fixed in 3.3: PyUnicode_Resize() always returns the
unicode_empty singleton.
Yeah, I tried to reuse singletons (empty string and latin-1 single
letters) as much as possible to reduce memory footprint, not to ensure
that an empty string is always the '' singleton.
I wouldn't call this a bug.
Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Introducing Electronic Contributor Agreements
On Mon, 04 Mar 2013 15:46:48 -0500 Terry Reedy tjre...@udel.edu wrote: On 3/4/2013 11:36 AM, Brett Cannon wrote: On Mon, Mar 4, 2013 at 11:30 AM, Brian Curtin br...@python.org mailto:br...@python.org wrote: The full announcement is at http://blog.python.org/2013/03/introducing-electronic-contributor.html, but a summary follows. We've now moved to an electronic Contributor License Agreement form at http://www.python.org/psf/contrib/contrib-form/ which will hopefully ease the signing and sending of forms for our potential contributors. The form shows the required fields whether you're signing as an individual or a representative of an organization, and removes the need to print, scan, fax, etc. When a new contributor fills in the form, they are emailed a copy of the form and asked to confirm the email address that they used (and received that copy at). Upon confirming, the signed form is sent to the PSF Administrator and filed away. The signature can either be generated from your typed name, or you can draw or upload your actual written signature if you choose. With this in place I would like to propose that all patches submitted to bugs.python.org http://bugs.python.org must come from someone who has signed the CLA before we consider committing it (if you want to be truly paranoid we could say that we won't even look at the code w/o a CLA). Either policy could be facilitated by tracker changes. In order to see the file upload box, one must login and the tracker knows who has a CLA on file (as indicated by a * suffix on the name). If a file is uploaded by someone without, a box could popup with the link to the e-form and a message that a CLA is required. And how about people who upload something else than a patch? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Planning on removing cache invalidation for file finders
On Sun, Mar 3, 2013 at 12:31 PM, Brett Cannon br...@python.org wrote: But how about this as a compromise over introducing write_module(): invalidate_caches() can take a path for something to specifically invalidate. The path can then be passed to the invalidate_caches() on sys.meta_path. In the case of PathFinder it would take that path, try to find the directory in sys.path_importer_cache, and then invalidate the most specific finder for that path (if there is one that has any directory prefix match). Lots of little details to specify (e.g. absolute path forced anywhere in case a relative path is passed in by sys.path is all absolute paths? How do we know something is a file if it has not been written yet?), but this would prevent importlib from subsuming file writing specifically for source files and minimize performance overhead of invalidating all caches for a single file. ISTR that when we were first discussing caching, I'd proposed a TTL-based workaround for the timestamp granularity problem, and it was mooted because somebody already proposed and implemented a similar idea. But my approach -- or at least the one I have in mind now -- would provide an eventual consistency guarantee, while still allowing fast startup times. However I think the experience with this heuristic so far shows that the real problem isn't that the heuristic doesn't work for the normal case; it works fine for that. Instead, what happens is that *it doesn't work when you generate modules*. And *that* problem can be fixed without even invalidating the caches: it can be fixed by doing some extra work when writing a module - e.g. by making sure the directory mtime changes again after the module is written. For example, create the module under a temporary name, verify that the directory mtime is different than it was before, then keep renaming it to different temporary names until the mtime changes again, then rename it to the final name. (This would be very fast on some platforms, much slower on others, but the OS itself would tell you when it had worked.) A utility routine to write_module() or write_package() would be easier to find than advice that says to invalidate the cache under thus-and-such conditions, as it would show up in searches for writing modules dynamically or creating modules dynamically, where you could only search for info about the cache if you knew the cache existed. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)
[Splitting into a separate thread] Do we really need to overthink something that requires a trivial alias to set up for one's own convenience? Picking a Python version (as Barry mentions) is just one of the problems. What's wrong with: alias rupytests='python3 -m unittest discover alias runpytests2='python2 -m unittest discover ? Don't get me wrong, I love the discover option and agree that it should be the recommended way to go - but isn't this largely a documentation issue? Eli On Mon, Mar 4, 2013 at 11:14 AM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. I hope we can have a pytest utility that does the right thing in 3.4 :-) Typing python -m unittest discover is too cumbersome. Where is this work being done (e.g. is there a PEP)? One thing to keep in mind is how to invoke this on a system with multiple versions of Python available. For example, in Debian, a decision was recently made to drop all the nosetests-X.Y scripts from /usr/bin[1]. This makes sense when you think about having at least two major versions of Python (2.x and 3.x) and maybe up to four (2.6, 2.7, 3.2, 3.3), *plus* debug versions of each. Add to that, we don't actually know at package build time which versions of Python you might have installed on your system. A suggestion was made to provide a main entry point so that `pythonX.Y -m nose` would work, which makes sense to me and was adopted by the nose-devs[2]. So while a top level `pytest` command may make sense, it also might not ;). While PEP 426 has a way to declare test dependencies (a good thing), it seems to have no way to declare how to actually run the tests. Cheers, -Barry [1] Start of thread: http://comments.gmane.org/gmane.linux.debian.devel.python/8572 [2] https://github.com/nose-devs/nose/issues/634 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/eliben%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Introducing Electronic Contributor Agreements
On 04/03/2013 20:46, Terry Reedy wrote: On 3/4/2013 11:36 AM, Brett Cannon wrote: On Mon, Mar 4, 2013 at 11:30 AM, Brian Curtin br...@python.org mailto:br...@python.org wrote: The full announcement is at http://blog.python.org/2013/03/introducing-electronic-contributor.html, but a summary follows. We've now moved to an electronic Contributor License Agreement form at http://www.python.org/psf/contrib/contrib-form/ which will hopefully ease the signing and sending of forms for our potential contributors. The form shows the required fields whether you're signing as an individual or a representative of an organization, and removes the need to print, scan, fax, etc. When a new contributor fills in the form, they are emailed a copy of the form and asked to confirm the email address that they used (and received that copy at). Upon confirming, the signed form is sent to the PSF Administrator and filed away. The signature can either be generated from your typed name, or you can draw or upload your actual written signature if you choose. With this in place I would like to propose that all patches submitted to bugs.python.org http://bugs.python.org must come from someone who has signed the CLA before we consider committing it (if you want to be truly paranoid we could say that we won't even look at the code w/o a CLA). Either policy could be facilitated by tracker changes. In order to see the file upload box, one must login and the tracker knows who has a CLA on file (as indicated by a * suffix on the name). If a file is uploaded by someone without, a box could popup with the link to the e-form and a message that a CLA is required. People already use the bug tracker as an excuse not to contribute, wouldn't this requirement make the situation worse? -- Cheers. Mark Lawrence ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)
On Mon, 4 Mar 2013 13:26:57 -0800 Eli Bendersky eli...@gmail.com wrote: [Splitting into a separate thread] Do we really need to overthink something that requires a trivial alias to set up for one's own convenience? Picking a Python version (as Barry mentions) is just one of the problems. What's wrong with: alias rupytests='python3 -m unittest discover alias runpytests2='python2 -m unittest discover ? Don't get me wrong, I love the discover option and agree that it should be the recommended way to go - but isn't this largely a documentation issue? I would personally call it a typing issue :-) python -m unittest discover is just too long. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)
On 5 March 2013 10:26, Eli Bendersky eli...@gmail.com wrote: [Splitting into a separate thread] Do we really need to overthink something that requires a trivial alias to set up for one's own convenience? The big thing is automated tools, not developers. When distributors want to redistribute packages they want to be sure they work. Running the tests is a pretty good signal for that, but having every package slightly different adds to the work they need to do. Being able to do 'setup.py test' consistently, everywhere - that would be great. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 3:45 PM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 03:40 PM, Daniel Holth wrote: On Mon, Mar 4, 2013 at 3:14 PM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 03:02 PM, Daniel Holth wrote: setup.py's setup(test_suite=x)... not sure if this is a distutils or setuptools feature. PEP 426 has an extension mechanism that could do the job. Shouldn't testing be a first order feature? Unfortunately there are so many potential first-order features that we've had to leave some out in order to save time. How to run the tests is not something that you need to know when searching PyPI for a distribution and its dependencies. Although has unittests that I can run might be a deciding factor of which of the many implementations of a particular feature you might choose. Sure, but that has nothing to do with programmatic package discovery. That's something you will have to do as a person in making a qualitative decision along the same lines as API design. Flipping a bit in a config file saying I have tests doesn't say much beyond you flipped a bit, e.g. no idea on coverage, quality, etc. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Introducing Electronic Contributor Agreements
On Mon, Mar 4, 2013 at 4:33 PM, Mark Lawrence breamore...@yahoo.co.ukwrote: On 04/03/2013 20:46, Terry Reedy wrote: On 3/4/2013 11:36 AM, Brett Cannon wrote: On Mon, Mar 4, 2013 at 11:30 AM, Brian Curtin br...@python.org mailto:br...@python.org wrote: The full announcement is at http://blog.python.org/2013/**03/introducing-electronic-** contributor.htmlhttp://blog.python.org/2013/03/introducing-electronic-contributor.html , but a summary follows. We've now moved to an electronic Contributor License Agreement form at http://www.python.org/psf/**contrib/contrib-form/http://www.python.org/psf/contrib/contrib-form/which will hopefully ease the signing and sending of forms for our potential contributors. The form shows the required fields whether you're signing as an individual or a representative of an organization, and removes the need to print, scan, fax, etc. When a new contributor fills in the form, they are emailed a copy of the form and asked to confirm the email address that they used (and received that copy at). Upon confirming, the signed form is sent to the PSF Administrator and filed away. The signature can either be generated from your typed name, or you can draw or upload your actual written signature if you choose. With this in place I would like to propose that all patches submitted to bugs.python.org http://bugs.python.org must come from someone who has signed the CLA before we consider committing it (if you want to be truly paranoid we could say that we won't even look at the code w/o a CLA). Either policy could be facilitated by tracker changes. In order to see the file upload box, one must login and the tracker knows who has a CLA on file (as indicated by a * suffix on the name). If a file is uploaded by someone without, a box could popup with the link to the e-form and a message that a CLA is required. People already use the bug tracker as an excuse not to contribute, wouldn't this requirement make the situation worse? Depends on your paranoia. If you're worried about accidentally lifting IP merely by reading someone's source code, then you wouldn't want to touch code without the CLA signed. Now I'm not that paranoid, but I'm still not about to commit someone's code now without the CLA signed to make sure we are legally covered for the patch. If someone chooses not to contribute because of the CLA that's fine, but since we have already told at least Anatoly that we won't accept patches from him until he signs the CLA I'm not going to start acting differently towards others. I view legally covering our ass by having someone fill in a form is worth the potential loss of some contribution in the grand scheme of things. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)
On Mar 05, 2013, at 11:01 AM, Robert Collins wrote: The big thing is automated tools, not developers. Exactly. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On Mar 04, 2013, at 05:04 PM, Brett Cannon wrote: Sure, but that has nothing to do with programmatic package discovery. That's something you will have to do as a person in making a qualitative decision along the same lines as API design. Flipping a bit in a config file saying I have tests doesn't say much beyond you flipped a bit, e.g. no idea on coverage, quality, etc. What I'm looking for is something that automated tools can use to easily discover how to run a package's tests. I want it to be dead simple for developers of a package to declare how their tests are to be run, and what extra dependencies they might need. It seems like PEP 426 only addresses the latter. Maybe that's fine and a different PEP is needed to describe automated test discover, but I still think it's an important use case. Imagine: * Every time you upload a package to PyPI, snakebite runs your test suite on a variety of Python versions and platforms. You get a nice link to the Jenkins results so you and your users get a good sense of overall package quality. * You have an automated gatekeeper that will prevent commits or uploads if your coverage or test results get worse instead of better. * Distro packagers can build tools that auto-discover the tests so that they are run automatically when the package is built, ensuring high quality packages specifically targeted to those distros. As a community, we know how important tests are, so I think our tools should reflect that and make it easy for those tests to be expressed. As a selfish side-effect, I want to reduce the amount of guesswork I need to perform in order to know how to run a package's test when I `$vcs clone` their repository. ;) Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Introducing Electronic Contributor Agreements
On 3/4/2013 3:46 PM, Antoine Pitrou wrote: On Mon, 04 Mar 2013 15:46:48 -0500 Terry Reedy tjre...@udel.edu wrote: On 3/4/2013 11:36 AM, Brett Cannon wrote: With this in place I would like to propose that all patches submitted to bugs.python.org http://bugs.python.org must come from someone who has signed the CLA before we consider committing it (if you want to be truly paranoid we could say that we won't even look at the code w/o a CLA). While I regard CLAs as partly being a form of legal theater, I regard our participation as necessary, both to make explicit to contributors what should be implicit in the act of submission *and* to show to copyright holders a good-faith effort to not improperly incorporate their code. Note: no one expected the Linux copyright challenge, nor our European trademark challenge, but they happened. I expect there will be more challenges to open source projects, perhaps some legitimate as the number of contributors increases. Either policy could be facilitated by tracker changes. In order to see the file upload box, one must login and the tracker knows who has a CLA on file (as indicated by a * suffix on the name). If a file is uploaded by someone without, a box could popup with the link to the e-form and a message that a CLA is required. And how about people who upload something else than a patch? Limit the popup to files with .diff or .patch extension. Reviewers can check for '*' for the occasionally patch lacking that. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)
On Mon, Mar 4, 2013 at 1:28 PM, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 4 Mar 2013 13:26:57 -0800 Eli Bendersky eli...@gmail.com wrote: [Splitting into a separate thread] Do we really need to overthink something that requires a trivial alias to set up for one's own convenience? Picking a Python version (as Barry mentions) is just one of the problems. What's wrong with: alias rupytests='python3 -m unittest discover alias runpytests2='python2 -m unittest discover ? Don't get me wrong, I love the discover option and agree that it should be the recommended way to go - but isn't this largely a documentation issue? I would personally call it a typing issue :-) python -m unittest discover is just too long. Command-line options for advanced capabilities can get long, yes. It's not a reason to add an extra layer, which is extra complexity, IMHO. The user is free to create his own shortcuts if this is too much typing. Moreover, many projects already have a way to run all tests from their root directory. As a case in point, we also have the useful: $ python -m SimpleHTTPServer So why not create a new pyserve command to reduce the amount of typing? Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)
On Mon, Mar 4, 2013 at 2:14 PM, Barry Warsaw ba...@python.org wrote: On Mar 05, 2013, at 11:01 AM, Robert Collins wrote: The big thing is automated tools, not developers. Exactly. I don't understand. Is python -m unittest discover too much typing for automatic tools? If anything, it's much more portable across Python versions since any new coommand/script won't be added before 3.4, while the longer version works in 2.7 and 3.2+ Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)
On 5 March 2013 12:49, Eli Bendersky eli...@gmail.com wrote: On Mon, Mar 4, 2013 at 2:14 PM, Barry Warsaw ba...@python.org wrote: On Mar 05, 2013, at 11:01 AM, Robert Collins wrote: The big thing is automated tools, not developers. Exactly. I don't understand. Is python -m unittest discover too much typing for automatic tools? If anything, it's much more portable across Python versions since any new coommand/script won't be added before 3.4, while the longer version works in 2.7 and 3.2+ It isn't about length. It is about knowing that *that* is what to type (and btw that exact command cannot run twisted's tests, among many other projects tests). Perhaps we are talking about different things. A top level script to run tests is interesting, but orthogonal to the thing Barry was asking for. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On 3 Mar 2013, at 01:29, Trent Nelson tr...@snakebite.org wrote: On Wed, Feb 27, 2013 at 08:51:16AM -0800, Michael Foord wrote: If you have other items you'd like to discuss please let me know and I can add them to the agenda. Hmm, seems like this might be a good forum to introduce the parallel/async stuff I've been working on the past few months. TL;DR version is I've come up with an alternative approach for exploiting multiple cores that doesn't rely on GIL-removal or STM (and has a negligible performance overhead when executing single-threaded code). (For those that are curious, it lives in the px branch of the sandbox/trent repo on hg.p.o, albeit in a very experimental/prototype/proof-of-concept state (i.e. it's an unorganized, undocumented, uncommented hackfest); on the plus side, it works. Sort of.) Second suggestion: perhaps a little segment on Snakebite? What it is, what's available to committers, feedback/kvetching from those who have already used it, etc. I've added both to the agenda. (I forgot the format of these summits -- is there a projector?) I've asked for a projector, yes. Michael Trent. -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On 3/4/2013 5:24 PM, Barry Warsaw wrote: What I'm looking for is something that automated tools can use to easily discover how to run a package's tests. I want it to be dead simple for developers of a package to declare how their tests are to be run, and what I am writing a package that has tests for each module (which I so far run individually for each module) using a custom test framework. I am planning to add a function to the package to run all of them. Should I call it 'testall', 'test_all', 'runtests', or something else? I really do not care. It would be used like this. import xxx; xxx.testall() Of course, this would not work with the stdlib since /lib is not a package that can be imported. I could put the same code in the top level of a module, to be run when imported (but that would not work with re-imports), or put the function in my test module. I am willing to adjust to a standard when there is one. What I do suggest is that package developers should only have to provide one standard entry point that hides all package-specific details. I presume the side-effect spec would be error messages to sdterr. Any return requirements should be a simple as possible, as in all pass True/False, or (number run, number fail) by whatever counting method the package/test framework uses. (Note: my framework does not count tests, as I only care about failure messages, but testall could count modules tested and those with a failure.) extra dependencies they might need. It seems like PEP 426 only addresses the latter. Maybe that's fine and a different PEP is needed to describe automated test discover, but I still think it's an important use case. New PEP. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On 5 Mar 2013 05:21, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. I hope we can have a pytest utility that does the right thing in 3.4 :-) Typing python -m unittest discover is too cumbersome. Where is this work being done (e.g. is there a PEP)? One thing to keep in mind is how to invoke this on a system with multiple versions of Python available. For example, in Debian, a decision was recently made to drop all the nosetests-X.Y scripts from /usr/bin[1]. This makes sense when you think about having at least two major versions of Python (2.x and 3.x) and maybe up to four (2.6, 2.7, 3.2, 3.3), *plus* debug versions of each. Add to that, we don't actually know at package build time which versions of Python you might have installed on your system. A suggestion was made to provide a main entry point so that `pythonX.Y -m nose` would work, which makes sense to me and was adopted by the nose-devs[2]. So while a top level `pytest` command may make sense, it also might not ;). While PEP 426 has a way to declare test dependencies (a good thing), it seems to have no way to declare how to actually run the tests. Metadata 2.0 won't cover that, 2.1 probably will. Please give us time to solve problems incrementally rather than trying to fix everything at once. Regards, Nick. Cheers, -Barry [1] Start of thread: http://comments.gmane.org/gmane.linux.debian.devel.python/8572 [2] https://github.com/nose-devs/nose/issues/634 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On 4 Mar 2013, at 06:26, Robert Collins robe...@robertcollins.net wrote: On 4 March 2013 18:54, Guido van Rossum gu...@python.org wrote: On Sun, Mar 3, 2013 at 9:24 PM, Robert Collins robe...@robertcollins.net wrote: I'd like to talk about overhauling - not tweaking, overhauling - the standard library testing facilities. That seems like too big a topic and too vague a description to discuss usefully. Perhaps you have a specific proposal? Or at least just a use case that's poorly covered? I have both - I have a draft implementation for a new test result API (and forwards and backwards compat code etc), and use cases that drive it. I started a thread here - http://lists.idyll.org/pipermail/testing-in-python/2013-February/005434.html , with blog posts https://rbtcollins.wordpress.com/2013/02/14/time-to-revise-the-subunit-protocol/ https://rbtcollins.wordpress.com/2013/02/15/more-subunit-needs/ https://rbtcollins.wordpress.com/2013/02/19/first-experience-implementing-streamresult/ https://rbtcollins.wordpress.com/2013/02/23/simpler-is-better/ They are focused on subunit, but much of subunit's friction has been due to issues encountered from the stdlibrary TestResult API - in particular three things: - the single-active-test model that the current API (or at least implementation) has. - the expectation that all test outcomes will originate from the same interpreter (or something with a live traceback object) - the inability to supply details about errors other than the exception All of which start to bite rather deep when working on massively parallel test environments. It is of course possible for subunit and related tools to run their own implementation, but it seems ideal to me to have a common API which regular unittest, nose, py.test and others can all agree on and use : better reuse for pretty printers, GUI displays and the like depend on some common API. TBH, your choice of words is ambiguous -- are you interested in overhauling the facilities for testing *of* the standard library (i.e. the 'test' package), or the testing facilities *provided by* the standard library (i.e. the unittest module)? Sorry! Testing facilities provided by the standard library. They should naturally facilitate testing of the standard library too. We can certainly talk about it - although as Guido says, something specific may be easier to have a useful discussion about. Reading through your blog articles it seemed like a whole lot of subunit context was required to understand the specific proposal you're making for the TestResult. It also *seems* like you're redesigning the TestResult for a single use case (distributed testing) with an api that looks quite odd for anything that isn't that use case. I'd rather see how we can make the TestResult play *better* with those requirements. That discussion probably belongs in another thread - or at the summit. Michael -Rob -- --Guido van Rossum (python.org/~guido) -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On 4 Mar 2013, at 19:26, Berker Peksağ berker.pek...@gmail.com wrote: On Mon, Mar 4, 2013 at 9:14 PM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. I hope we can have a pytest utility that does the right thing in 3.4 :-) Typing python -m unittest discover is too cumbersome. Where is this work being done (e.g. is there a PEP)? There is an open issue on the tracker: http://bugs.python.org/issue14266 Indeed, and unittest2 (the backport) which has to work with Python 2.6 (where python -m package_name doesn't work) has unit2 as a shortcut. So it has an advantage over the standard library version here. I'd like to see pyunit as a short-cut for python -m unittest discover, with a pyunit-3.x variant too. Barry objects that Linux distributions won't want to support all of these, which is frankly their problem. Michael --Berker ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On 5 March 2013 13:21, Michael Foord fuzzy...@voidspace.org.uk wrote: We can certainly talk about it - although as Guido says, something specific may be easier to have a useful discussion about. Reading through your blog articles it seemed like a whole lot of subunit context was required to understand the specific proposal you're making for the TestResult. It also *seems* like you're redesigning the TestResult for a single use case (distributed testing) with an api that looks quite odd for anything that isn't that use case. I'd rather see how we can make the TestResult play *better* with those requirements. That discussion probably belongs in another thread - or at the summit. Right - all I wanted was to flag that you and I and any other interested parties should discuss this at the summit :). -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On 28 Feb 2013, at 13:49, Brett Cannon br...@python.org wrote: On Thu, Feb 28, 2013 at 6:34 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: On 28 Feb 2013, at 07:36, Georg Brandl g.bra...@gmx.net wrote: Am 27.02.2013 17:51, schrieb Michael Foord: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings If you have other items you'd like to discuss please let me know and I can add them to the agenda. May I in absentia propose at least a short discussion of the XML fixes and accompanying security releases? FWIW, for 3.2 and 3.3 I have no objections to secure-by-default. Sure. It would be good if someone who *will* be there can champion the discussion. While Christian is in the best position to discuss this, I did review his various monkeypatch fixes + expat patches so I can attempt to answer any questions people may have. I've put you next to the topic in the agenda Brett :-) Michael -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On 4 Mar 2013, at 20:02, Daniel Holth dho...@gmail.com wrote: On Mon, Mar 4, 2013 at 2:26 PM, Berker Peksağ berker.pek...@gmail.com wrote: On Mon, Mar 4, 2013 at 9:14 PM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. I hope we can have a pytest utility that does the right thing in 3.4 :-) Typing python -m unittest discover is too cumbersome. Where is this work being done (e.g. is there a PEP)? There is an open issue on the tracker: http://bugs.python.org/issue14266 --Berker setup.py's setup(test_suite=x)... not sure if this is a distutils or setuptools feature. PEP 426 has an extension mechanism that could do the job. This is a setuptools extension. There was some discussion for packaging/distutils2 of having test support but I have no idea if that has been picked up for the new bunch of packaging related work. Michael ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)
On Mon, Mar 4, 2013 at 4:09 PM, Robert Collins robe...@robertcollins.netwrote: On 5 March 2013 12:49, Eli Bendersky eli...@gmail.com wrote: On Mon, Mar 4, 2013 at 2:14 PM, Barry Warsaw ba...@python.org wrote: On Mar 05, 2013, at 11:01 AM, Robert Collins wrote: The big thing is automated tools, not developers. Exactly. I don't understand. Is python -m unittest discover too much typing for automatic tools? If anything, it's much more portable across Python versions since any new coommand/script won't be added before 3.4, while the longer version works in 2.7 and 3.2+ It isn't about length. It is about knowing that *that* is what to type (and btw that exact command cannot run twisted's tests, among many other projects tests). Perhaps we are talking about different things. A top level script to run tests is interesting, but orthogonal to the thing Barry was asking for. Perhaps :-) I'm specifically referring to a new top-level script that will run all unittests in discovery mode from the current directory, as a shortcut to python -m unittest discover. ISTM this is at leas in part what was discussed, and my email was in this context. Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On 1 Mar 2013, at 18:38, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 1 Mar 2013 09:32:23 -0500 Barry Warsaw ba...@python.org wrote: On the other hand in some ways Jython is sort of like Python on a weird virtual OS that lets the real OS bleed through some. This may still need to be checked in that way (there's are still checks of if os.name == 'nt' right?) Yeah, but that all old code ;) Hmm, what do you mean? `os.name == 'nt'` is still the proper way to test that we're running on a Windows system (more accurately, over the Windows API). It has been used incorrectly in a few places in the Python standard library - Windows support code that would work correctly on IronPython is skipped because os.name is *not* 'nt' on IronPython. That was the case in the past anyway. It's quite some time since I've used IronPython now. Michael Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)
On 5 March 2013 13:35, Eli Bendersky eli...@gmail.com wrote: Perhaps :-) I'm specifically referring to a new top-level script that will run all unittests in discovery mode from the current directory, as a shortcut to python -m unittest discover. ISTM this is at leas in part what was discussed, and my email was in this context. So that is interesting, but its not sufficient to meet the automation need Barry is calling out, unless all test suites can be run by 'python -m unittest discover' with no additional parameters [and a pretty large subset cannot]. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Introducing Electronic Contributor Agreements
On 04/03/2013 22:08, Brett Cannon wrote: On Mon, Mar 4, 2013 at 4:33 PM, Mark Lawrence breamore...@yahoo.co.uk mailto:breamore...@yahoo.co.uk wrote: On 04/03/2013 20:46, Terry Reedy wrote: On 3/4/2013 11:36 AM, Brett Cannon wrote: On Mon, Mar 4, 2013 at 11:30 AM, Brian Curtin br...@python.org mailto:br...@python.org mailto:br...@python.org mailto:br...@python.org wrote: The full announcement is at http://blog.python.org/2013/__03/introducing-electronic-__contributor.html http://blog.python.org/2013/03/introducing-electronic-contributor.html, but a summary follows. We've now moved to an electronic Contributor License Agreement form at http://www.python.org/psf/__contrib/contrib-form/ http://www.python.org/psf/contrib/contrib-form/ which will hopefully ease the signing and sending of forms for our potential contributors. The form shows the required fields whether you're signing as an individual or a representative of an organization, and removes the need to print, scan, fax, etc. When a new contributor fills in the form, they are emailed a copy of the form and asked to confirm the email address that they used (and received that copy at). Upon confirming, the signed form is sent to the PSF Administrator and filed away. The signature can either be generated from your typed name, or you can draw or upload your actual written signature if you choose. With this in place I would like to propose that all patches submitted to bugs.python.org http://bugs.python.org http://bugs.python.org must come from someone who has signed the CLA before we consider committing it (if you want to be truly paranoid we could say that we won't even look at the code w/o a CLA). Either policy could be facilitated by tracker changes. In order to see the file upload box, one must login and the tracker knows who has a CLA on file (as indicated by a * suffix on the name). If a file is uploaded by someone without, a box could popup with the link to the e-form and a message that a CLA is required. People already use the bug tracker as an excuse not to contribute, wouldn't this requirement make the situation worse? Depends on your paranoia. If you're worried about accidentally lifting IP merely by reading someone's source code, then you wouldn't want to touch code without the CLA signed. Now I'm not that paranoid, but I'm still not about to commit someone's code now without the CLA signed to make sure we are legally covered for the patch. If someone chooses not to contribute because of the CLA that's fine, but since we have already told at least Anatoly that we won't accept patches from him until he signs the CLA I'm not going to start acting differently towards others. I view legally covering our ass by having someone fill in a form is worth the potential loss of some contribution in the grand scheme of things. Who's talking source code, you're previously mentioned *ALL* patches needing a CLA. Does this mean you have to sign a CLA for a one line documentation patch? What is the definition of a patch, an actual patch file or a proposal for a change that is given within a bug tracker message? -- Cheers. Mark Lawrence ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On 5 Mar 2013, at 00:23, Robert Collins robe...@robertcollins.net wrote: On 5 March 2013 13:21, Michael Foord fuzzy...@voidspace.org.uk wrote: We can certainly talk about it - although as Guido says, something specific may be easier to have a useful discussion about. Reading through your blog articles it seemed like a whole lot of subunit context was required to understand the specific proposal you're making for the TestResult. It also *seems* like you're redesigning the TestResult for a single use case (distributed testing) with an api that looks quite odd for anything that isn't that use case. I'd rather see how we can make the TestResult play *better* with those requirements. That discussion probably belongs in another thread - or at the summit. Right - all I wanted was to flag that you and I and any other interested parties should discuss this at the summit :). I've added a testing topic to the agenda. At the very least you could outline your streaming test result proposal, or kick off a meta discussion. We'll probably time limit the discussion so some specific focus will make it more productive - or maybe you can get a feel for how open to major changes in this area other python devs are. Michael -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On 5 March 2013 13:50, Michael Foord fuzzy...@voidspace.org.uk wrote: Right - all I wanted was to flag that you and I and any other interested parties should discuss this at the summit :). I've added a testing topic to the agenda. At the very least you could outline your streaming test result proposal, or kick off a meta discussion. We'll probably time limit the discussion so some specific focus will make it more productive - or maybe you can get a feel for how open to major changes in this area other python devs are. Cool. I can step through the core use cases and differences to what TestResult is in pretty short order. We can spider out from there as folk desire. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On 4 Mar 2013, at 22:24, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 05:04 PM, Brett Cannon wrote: Sure, but that has nothing to do with programmatic package discovery. That's something you will have to do as a person in making a qualitative decision along the same lines as API design. Flipping a bit in a config file saying I have tests doesn't say much beyond you flipped a bit, e.g. no idea on coverage, quality, etc. What I'm looking for is something that automated tools can use to easily discover how to run a package's tests. I want it to be dead simple for developers of a package to declare how their tests are to be run, and what extra dependencies they might need. It seems like PEP 426 only addresses the latter. Maybe that's fine and a different PEP is needed to describe automated test discover, but I still think it's an important use case. Imagine: * Every time you upload a package to PyPI, snakebite runs your test suite on a variety of Python versions and platforms. You get a nice link to the Jenkins results so you and your users get a good sense of overall package quality. * You have an automated gatekeeper that will prevent commits or uploads if your coverage or test results get worse instead of better. * Distro packagers can build tools that auto-discover the tests so that they are run automatically when the package is built, ensuring high quality packages specifically targeted to those distros. As a community, we know how important tests are, so I think our tools should reflect that and make it easy for those tests to be expressed. As a selfish side-effect, I want to reduce the amount of guesswork I need to perform in order to know how to run a package's test when I `$vcs clone` their repository. ;) Distutils2 had a way of specifying this in the metadata. It looks like this hasn't made it into the reboot: http://alexis.notmyidea.org/distutils2/distutils/newcommands.html Michael Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On 4 Mar 2013, at 20:00, Robert Collins robe...@robertcollins.net wrote: On 5 March 2013 05:34, Brett Cannon br...@python.org wrote: On Mon, Mar 4, 2013 at 11:29 AM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:26 PM, Robert Collins wrote: It is of course possible for subunit and related tools to run their own implementation, but it seems ideal to me to have a common API which regular unittest, nose, py.test and others can all agree on and use : better reuse for pretty printers, GUI displays and the like depend on some common API. And One True Way of invoking and/or discovering how to invoke, a package's test suite. How does unittest's test discovery not solve that? Three reasons a) There are some bugs (all filed I think) - I intend to hack on these in the near future - that prevent discovery working at all for some use cases. The only discovery related issues I'm aware of are: * Issue 16079 (filed by you) - trivial to fix just needs a test * Issue 15010 obscure and unlikely to be an issue for standard discovery I'm not aware of any other discovery related issues. Please let me know (or add me as nosy) to them. b) discovery requires magic parameters that are project specific (e.g. is it 'discover .' or 'discover . lib' to run it). This is arguably a setup.py/packaging entrypoint issue. This was addressed by Barry - and yes discovery has to be done with the right parameters. If you layout your project in a particular way then python -m unittest discover in the project root will just work. This is project specific metadata though and not a particular problem of any testing library. c) Test suites written for e.g. Twisted, or nose, or other non-stdunit-runner-compatible test runners will fail to execute even when discovered correctly. There are ways to solve this without addressing a/b/c - just defining a standard command to run that signals success/failure with it's exit code. Packages can export a particular flavour of that in their setup.py if they have exceptional needs, and do nothing in the common case. That doesn't solve 'how to introspect a package test suite' but for distro packagers - and large scale CI integration - that doesn't matter. For instance testrepository offers a setuptools extension to let it be used trivially, I believe nose does something similar. unittest2 also has setuptools compatible test command. Having something that would let *any* test suite spit out folk's favourite test protocol de jour would be brilliant of course :). [junit-xml, subunit, TAP, ...] Yes. Michael -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] running tests; mebs
As a community, we know how important tests are, so I think our tools should reflect that and make it easy for those tests to be expressed. As a selfish side-effect, I want to reduce the amount of guesswork I need to perform in order to know how to run a package's test when I `$vcs clone` their repository. ;) Distutils2 had a way of specifying this in the metadata. It looks like this hasn't made it into the reboot: http://alexis.notmyidea.org/distutils2/distutils/newcommands.html Michael Cheers, -Barry I'm not aware of a reboot of the setup.py replacement / improvement effort. The work that has been done has proceeded backwards from the installer end of things. I had a proposal called mebs, not an actual project. A completely plugin-based system would recognize any sdist format and provide a minimal, consistent interface. Add tests to the below text from October. ... A very simple meta-build system mebs is used to recognize sdists and build binary packages. Build systems provide plugins having three methods, .recognize() .metadata() .build() An installer downloads an sdist. For each installed build plugin, .recognize(dir) is called. The first plugin to return True is used. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)
On Mar 05, 2013, at 01:09 PM, Robert Collins wrote: It isn't about length. It is about knowing that *that* is what to type (and btw that exact command cannot run twisted's tests, among many other projects tests). Perhaps we are talking about different things. A top level script to run tests is interesting, but orthogonal to the thing Barry was asking for. Right, two different things. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Introducing Electronic Contributor Agreements
Mark Lawrence writes: People already use the bug tracker as an excuse not to contribute, wouldn't this requirement make the situation worse? A failure to sign the CLA is already a decision not to contribute to the distribution, no matter how noisy they are on the tracker and list. I think that pretty much any upload is potential content for inclusion in Python. For example, uploading a log of an interactive session reproducing a bug could easily evolve into contribution of a doctest. Since the proposed page only triggers on uploads, I think we're in yes, we really do want this person's CLA territory. The procedure is actually rather cool. As Eli says, the tough part is finding your user name, but OpenID or browser memory makes that reasonably close to trivial for many people. It's true that people upload one-line documentation patches, and these don't require a CLA under even the most paranoid interpretation of US law. The FSF's guideline is 16 lines, I believe. However, the FSF's guideline also says those 16 lines are lifetime cumulative (per copyrighted work, but we're only talking about one, Python). In my experience (with a different project, so FWIW) somebody who goes to the trouble of uploading a doc typo patch is likely to be a repeat offender, whereas drive-by contributors who just need that one feature so their web2.0 app works as desired are often going to be in 16-line territory anyway. This argument doesn't catch 100% of those who might be deterred by the popup, but it's definitely enough to make the popup worthwhile. IANAL-but-I-like-a-good-license-flamewar-as-much-as-the-next-guy-ly y'rs, ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 4:39 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: On 1 Mar 2013, at 18:38, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 1 Mar 2013 09:32:23 -0500 Barry Warsaw ba...@python.org wrote: On the other hand in some ways Jython is sort of like Python on a weird virtual OS that lets the real OS bleed through some. This may still need to be checked in that way (there's are still checks of if os.name == 'nt' right?) Yeah, but that all old code ;) Hmm, what do you mean? `os.name == 'nt'` is still the proper way to test that we're running on a Windows system (more accurately, over the Windows API). It has been used incorrectly in a few places in the Python standard library - Windows support code that would work correctly on IronPython is skipped because os.name is *not* 'nt' on IronPython. That was the case in the past anyway. It's quite some time since I've used IronPython now. I think you misremembered - there's lots of code that uses `sys.platform == 'win32'` to detect Windows, but sys.platform is 'cli' for IronPython. I'm pretty sure `os.name has always been 'nt' (when running on Windows), and if not, it definitely is now. Jython sets os.name to 'java' (IIRC), so there isn't a uniform way to detect Windows across all implementations. - Jeff ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)
On Tue, Mar 5, 2013 at 1:41 AM, Robert Collins robe...@robertcollins.net wrote: So that is interesting, but its not sufficient to meet the automation need Barry is calling out, unless all test suites can be run by 'python -m unittest discover' with no additional parameters [and a pretty large subset cannot]. But can they be changed so they are? That's gotta be the important bit. What's needed here is not a tool that can run all unittests in existence, but an official way for automated tools to run tests, with the ability for any test and test framework to hook into that, so that you can run any test suite automatically from an automated tool. The, once that mechanism has been identified/implemented, we need to tell everybody to do this. I don't care much what that mechanism is, but I think the easiest way to get there is to tell people to extend distutils with a test command (or use Distribute) and perhaps add such a command in 3.4 that will do the unittest discover thingy. I remember looking into zope.testrunner hooking into that mechanism as well, but I don't remember what the outcome was. //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)
On Tuesday, March 5, 2013 at 2:02 AM, Lennart Regebro wrote: On Tue, Mar 5, 2013 at 1:41 AM, Robert Collins robe...@robertcollins.net (mailto:robe...@robertcollins.net) wrote: So that is interesting, but its not sufficient to meet the automation need Barry is calling out, unless all test suites can be run by 'python -m unittest discover' with no additional parameters [and a pretty large subset cannot]. But can they be changed so they are? That's gotta be the important bit. What's needed here is not a tool that can run all unittests in existence, but an official way for automated tools to run tests, with the ability for any test and test framework to hook into that, so that you can run any test suite automatically from an automated tool. The, once that mechanism has been identified/implemented, we need to tell everybody to do this. I don't care much what that mechanism is, but I think the easiest way to get there is to tell people to extend distutils with a test command (or use Distribute) and perhaps add such a command in 3.4 that will do the unittest discover thingy. I remember looking into zope.testrunner hooking into that mechanism as well, but I don't remember what the outcome was. Doesn't setuptools/distribute already have a setup.py test command? That seems like the easiest way forward? //Lennart ___ Python-Dev mailing list Python-Dev@python.org (mailto:Python-Dev@python.org) http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)
On 5 March 2013 20:02, Lennart Regebro rege...@gmail.com wrote: On Tue, Mar 5, 2013 at 1:41 AM, Robert Collins robe...@robertcollins.net wrote: So that is interesting, but its not sufficient to meet the automation need Barry is calling out, unless all test suites can be run by 'python -m unittest discover' with no additional parameters [and a pretty large subset cannot]. But can they be changed so they are? That's gotta be the important bit. In principle maybe. Need to talk with the trial developers, nose developers, py.test developers etc - to get consensus on a number of internal API friction points. What's needed here is not a tool that can run all unittests in existence, but an official way for automated tools to run tests, with the ability for any test and test framework to hook into that, so that you can run any test suite automatically from an automated tool. The, once that mechanism has been identified/implemented, we need to tell everybody to do this. I think the command line is the right place to do that - declare as metadata the command line to run a packages tests. I don't care much what that mechanism is, but I think the easiest way to get there is to tell people to extend distutils with a test command (or use Distribute) and perhaps add such a command in 3.4 that will do the unittest discover thingy. I remember looking into zope.testrunner hooking into that mechanism as well, but I don't remember what the outcome was. Agreed. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)
On Mon, 4 Mar 2013 15:47:37 -0800 Eli Bendersky eli...@gmail.com wrote: On Mon, Mar 4, 2013 at 1:28 PM, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 4 Mar 2013 13:26:57 -0800 Eli Bendersky eli...@gmail.com wrote: [Splitting into a separate thread] Do we really need to overthink something that requires a trivial alias to set up for one's own convenience? Picking a Python version (as Barry mentions) is just one of the problems. What's wrong with: alias rupytests='python3 -m unittest discover alias runpytests2='python2 -m unittest discover ? Don't get me wrong, I love the discover option and agree that it should be the recommended way to go - but isn't this largely a documentation issue? I would personally call it a typing issue :-) python -m unittest discover is just too long. Command-line options for advanced capabilities can get long, yes. The whole point is that discovery is not advanced capability, it's pretty basic by today's standards. So it should actually be the default behaviour (like it is with nose). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Introducing Electronic Contributor Agreements
On 3/4/2013 7:51 PM, Mark Lawrence wrote: Who's talking source code, you're previously mentioned *ALL* patches needing a CLA. Does this mean you have to sign a CLA for a one line documentation patch? It it is a one char typo, I would not bother downloading the patch, or adding a person to ACKS. If the patch is big enough to download and apply, then I want a CLA. If a person is sophisticated enough to submit a respository file diff, they are likely to submit more, and I want them to feel encouraged to do so by already having done the CLA. If we do not get it with the first submission, then when? Who keeps track of cumulative lines? What is the definition of a patch, an actual patch file Usually. or a proposal for a change that is given within a bug tracker message? I view a proposal for a change as just an idea. Such usually get re-written by whoever creates an actual patch. I would like the link to the e-form to be accessible somewhere on the tracker so I can refer people to it easily. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
