Re: [Python-Dev] Maintaining old releases
On Thu, Aug 14, 2008, M.-A. Lemburg wrote: > On 2008-08-14 08:43, Martin v. L?wis wrote: >>>For example, let's project dates for closing 2.6 and 3.0 now, and add >>>them to PEP 361. >> >>My view is that they should be closed when 2.7 and 3.1 are released. > > Since we don't have a fixed release cycle, making the 2.(n-1) > maintenance time frame depend on the 2.n release is not a reliable way > of defining the 2.(n-1) lifetime. > > Instead, we should fix the dates based on the 2.(n-1) release date. Why? As Brett pointed out, we simply don't have the infrastructure to maintain multiple releases -- if we force time-based maintenance, it won't work. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ Adopt A Process -- stop killing all your children! ___ 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] Looking for an up-to-date address for john.benediktsson
Brett Cannon wrote: > I was going through our list of email addreses for committers and > realized that I don't have an address for john.benediktsson that > works; his ewtllc.com address is bouncing. Anyone have an up-to-date > one? Replied privately. ___ 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-committers] PQM?
Christian Heimes wrote: > Perhaps we could adopt a release plan similar to Ubuntu. They have > releases with cool, new and bleeding edge stuff followed by a release > that focuses on stability and long term support. Python 2.6 and > especially 3.0 are releases with new features. What do you think about > focusing on stability and long time support for 2.7 and 3.1? 2.7 might > be the last version of the 2.x series and we sure gonna have to fix lots > of issues in the 3.x series until it's matured. I actually thought that was the plan for 2.7/3.1 ever since Guido started talking about Py3k as a real thing instead of a "at some unspecified time in the future" activity. (Well, for 3.1 anyway - 2.6 should be as rock solid as we can make it, but 3.0 is going to have issues with availability of third party extensions no matter how solid or otherwise the core might be) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Looking for an up-to-date address for john.benediktsson
I was going through our list of email addreses for committers and realized that I don't have an address for john.benediktsson that works; his ewtllc.com address is bouncing. Anyone have an up-to-date one? -Brett ___ 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] Fwd: PEP: Frequently-requested additional features for the `unittest` module
> > Abstract > > > This PEP proposes frequently-requested additions to the standard > library `unittest` module that are natural extensions of its existing > functionality. > I had not seen this proposal... I will post a few comments. > > Motivation > == > > The `unittest` module is functionally complete. Nevertheless, many > users request and devise extensions to perform functions that are so > common they deserve to be in the standard module. > > > Specification > = > > New condition tests > --- > > The following test methods will be added to the ``TestCase`` class. > The function signature is part of this specification. The body is to > be treated as a reference implementation only; any functionally > identical implementation also meets this specification. > ... > > The following test methods are also added. Their implementation in > each case is simply the logical inverse of a corresponding method > above. > My question here is... should assert* (fail*) methods be included in a separate class or module? I think this is a good idea (at least in the long term) Take a look at the following thread [1] for further details > > Simple invocation of test collection > > > The following new functionality will be added to the `unittest` > module. The function signature for ``run_tests`` is part of this > specification; the implementation is to be considered a reference > implementation only. > > :: > > def run_tests( > tests, > loader_class=TestLoader, suite_class=TestSuite, > runner_class=TextTestRunner): > """ Run a collection of tests with a test runner > > :param tests: > A sequence of objects that can contain test cases: > modules, `TestSuite` instances, or `TestCase` > subclasses. > :param loader_class: > The type of test loader to use for collecting tests > from the `tests` collection. > :param suite_class: > The type of test suite to use for accumulating the > collected test cases. > :param runner_class: > The type of test runner to instantiate for running the > collected test cases. > :return: > None. > > """ > I suppose that the reason for this function to exist is to ease test code (provide a shortcut or something), reuse some test code, and still allow different loading, running strategies. However, I dont think that passing (loader / suite / runner) classes in to this function is a good idea... IMO objects should be considered instead... Why? Mainly because the code assumes that all loaders are stateless. This may be true for unittest's and perhaps others, but this might not always be true. An example of statefull test loaders might be found in [2] (presented in [3]), and perhaps there other examples like this (even though I don't know them). This kind of code might restrain the use of this kind of loaders, and therefore might not be as reusable as should be. Nonetheless, you might think this is a very peculiar case and decide that this comment is irrelevant, but as far as I know, semantics of unittest TestLoader do not enforce that its subclasses ought to be stateless (although, I repeat, unittest test loaders are stateless). The same might be said for test runners... and they are more likely to be stateful. > def iter_testcases_recursively(collection, loader): > # Flatten and iterate over collection, generating > # instances of TestCase > loader = loader_class() > suite = suite_class() > for testcase in iter_testcases_recursively(tests, loader): > suite.add_tests(testcase) > runner = runner_class() > runner.run(suite) Besides... why is it necessary to flatten a hierarchy of test suites containing test cases? Why do you need to put them into another suite if the test loader already does this for us? Isn't it an extra overhead? Also there is a class attribute (`suiteClass`) in TestLoader which allows doing something like this. [1][Python-Dev] unittest Suggestions (http://mail.python.org/pipermail/python-dev/2008-August/081763.html) [2]Module dutest (https://sourceforge.net/project/showfiles.php?group_id=220287&abmode=1) [3][Python-Dev] An OO API for doctest / unittest integration... (http://mail.python.org/pipermail/python-dev/2008-August/081761.html) -- Regards, Olemis. ___ 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-
[Python-Dev] uuid test fails
Hi, I thought I'd bring this up on both the tracker and mailing list, since it's important. It seems the test suite breaks as of r65661. I've posted details to the bug tracker and a patch which fixes the module in question (uuid.py). http://bugs.python.org/issue3552 Cheers Matt ___ 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] unittest Suggestions
On Aug 14, 2008, at 8:13 AM, Olemis Lang wrote: What I do think is that we need a mail list (or equivalent) dedicated to discuss such things... because (again IMO) python-dev might not be It's not, but this list is the right place: http://lists.idyll.org/listinfo/testing-in-python -Fred -- Fred Drake ___ 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] unittest Suggestions
> > > > > The goal > > > should be to produce something like a unittest-ng, distribute it via > > > the Cheeseshop, and gather consensus around it for possible inclusion > > > in Python 2.7/3.1. > > > > > IMO test support in Python needs some enhancements. I also think there are great libraries available today in Python (stdlib)... but you know... other frameworks (e.g. JUnit, NUnit, ...) have evolved in order to support more effective practices and also to satisfy new requirements present in more complex test environments and ... and improvements are really necessary. That's why... > unittest.asserts > > > Currently all assertions reside as methods on the TestCase class. This > means that all testing functions, including utility functions, need to be > on a TestCase-derived class. This seems wrong to me, especially since it > combines different concerns on a class: Testing the functionality of a > SUT, running a test suite, and providing test functions. I agree... > This proposal > will not try to separate the first two concerns, but only the third one. I think this is cool... > In the long term I think it's worthwhile to make tests work on any > class, not only on classes derived from TestCase, but as I said, this is > not part of this proposal. > I am not very sure about this... even though I love doctest, and you can define that kind of tests in almost every class... but I think this case is different since doctests have an additional value... Users can quickly and easily see example usage while they are looking for help. IMO today (I would like you to make me change my mind) this could lead to test code mixed with the functionality of (for example) a class... and at least now I don't see the benefits. > JUnit 4 moved the assertions to a static class in a separate module. In > Python I'd propose to use functions in a separate module. I agree 100% with this... However, I think that TestCase assert* (or fail*, as you wish... that's another thread) methods should remain available for a while so as to avoid breaking third party (and perhaps stdlib) test code. But conceptually I think this is ok. It'd be precise to evaluate how much convinient it is in practice. About the rest... I will have further comments once I see this... in action ;-). > > There is already unittest, nose, py.test, trial... perhaps others I don't > know > > of. I fear writing yet another testing framework from the ground-up will > lead to > > more bikeshedding and less focussed discussion (see some testing-in-python > > threads for an example :-)). > > I think there should be a consensus about which are the most relevant improvements needed nowadays in this field. The weaknesses and strong points. And also what will be considered standard and what will be considered third party modules (because including every library code available, or a particular framework as a whole, "might" not be a good idea). And this does not mean that some code that is available and distributed under "appropriate" terms will (can) not be included in the future, nor that a new test framework ought to be built from scratch. I mean that both kinds of decisions should be made considering some kind of "requirements" or "milestones" which clearly state what should (needs to) be done... and perhaps this could be the first milestone to avoid chaos. What I do think is that we need a mail list (or equivalent) dedicated to discuss such things... because (again IMO) python-dev might not be the best place to talk about these topics. Or what is the same... there should be a place (preferently here in python.org) to talk about this topics in detail, without interfering with the development of the language itself. The relevant decisions and ideas might be communicated somehow (e.g. informational / ST / Process PEPs, guidelines) in order to "keep focused". > Incremental > improvements with backwards compatibility are a great thing. I agree... > I very > strongly encourage that course of action. It has already happened a number > of times in this thread that some proposed functionality already exists in > some third-party unittest extension and could easily be moved into the > stdlib unittest module. That's a good thing: it shows that the > functionality > is actually valuable and it makes it easy to include, since it's already > implemented. > Yes... this is right when "we all" agree on what "we" want and find out that the library turns "our dreams" into "reality". -- Regards, Olemis. ___ 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] pybsddb 4.7.3pre1: Compatibility with Python 3.0
Jesus Cea wrote: I plan to release pybsddb 4.7.3 in mid-september, ready to be delivered bundled in Python 2.6/3.0 (to be released early in october). Jesus, I think your target date is off by a month - it may be better to try and land an initial cut of this in Python SVN for beta 3 (August 20), rather than hoping to make significant changes after the first release candidate (which is currently slated for September 3). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Maintaining old releases
On 2008-08-14 08:43, Martin v. Löwis wrote: For example, let's project dates for closing 2.6 and 3.0 now, and add them to PEP 361. My view is that they should be closed when 2.7 and 3.1 are released. Since we don't have a fixed release cycle, making the 2.(n-1) maintenance time frame depend on the 2.n release is not a reliable way of defining the 2.(n-1) lifetime. Instead, we should fix the dates based on the 2.(n-1) release date. Following another informal policy, we were going for an 18 months release cycle at some time (2.6 clearly took longer), which would mean that those branches get closed on March 1, 2010. Security releases will be available until October 1, 2013. That would only allow 1.5 years for bug fixes - we were discussing 3 years for bug fixes and another 2 years for security fixes, ie. 2.6 bug fixes until Oct 01 2011 2.6 security fixes until Oct 01 2013 Ditto for 3.0. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 14 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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
