On 8/20/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
I think fixing tests and documentation would be a great thing to focus 2.6 on. Not glamourous, I know, but it is needed.
For tests, I hope to get some decorators and such written that will help classify tests. Also adding a function to denote what module is being tested would be good (to avoid the issue of a dependent import for testing failing and then everyone just thinking the test was skipped). Lastly, testing the C API using ctypes would be really good since it is not thorougly tested.
As for the docs, they just need a thorough updating. As to whether we should come up with some other format for Py3K with better semantic information and that is easier to read is another question entirely.
-Brett
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Aug 20, 2006, at 11:24 AM, Guido van Rossum wrote:
> I wonder if it would make sense to focus in 2.6 on making porting of
> 2.6 code to 3.0 easier, rather than trying to introduce new features
> in 2.6. We've done releases without new language features before;
> notable 2.3 didn't add anything new (except making a few __future__
> imports redundant) and concentrated on bugfixes, performance, and
> library additions.
+1, and there are other benefits to this approach too.
First, the pace of change appears to slow, which addresses another
source of complaints. Because instead of a slew of new features
every 18 months, we really see that slew only every three years, with
a stabilizing and bug fixing release in between. Another benefit is
that with a de-emphasis on new features, we can spend more time
improving the library and documentation.
I think fixing tests and documentation would be a great thing to focus 2.6 on. Not glamourous, I know, but it is needed.
For tests, I hope to get some decorators and such written that will help classify tests. Also adding a function to denote what module is being tested would be good (to avoid the issue of a dependent import for testing failing and then everyone just thinking the test was skipped). Lastly, testing the C API using ctypes would be really good since it is not thorougly tested.
As for the docs, they just need a thorough updating. As to whether we should come up with some other format for Py3K with better semantic information and that is easier to read is another question entirely.
-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
