At 04:59 PM 6/28/2007 +0100, tav wrote: >* Abandoning of unit tests and replacing with full doctest coverage in >the style perfected by Jim Fulton and PJE. Integration with py.test.
I believe that the origination credit for this rightly falls to Tim Peters. (I just copied Jim, myself.) Meanwhile, there are quite a few stdlib doctests now, and unittests still more than have their place. Indeed, I'm also wary of breaking backward compatibility of unittest or doctest in Python 3.0, because that will make it even harder to port code over. How will 2.x users run their existing test suites to verify their code has been ported correctly, if they can't keep using unittest? As it is, they'll have to run them through 2to3, which AFAIK doesn't do doctests currently. >* Ability to import from remote networked sources, e.g. import >http://foo.com/blah/ A strong -1 on any import system that breaks down the current strict separation between module names and module *locations*. Too many people confuse these concepts already, and we already have a nicely field-tested mechanism for specifying locations and turning them into importer objects. >* Authentication of sources with configurable crypto. > >* Full integration with setuptools + eggs. > >* Pluggable integration support for version control systems like svn/bzr. > >* Builtin versioning support for modules. > >* Live-update of modules/code support (in the vein of Erlang). > >* Rewrite of standard library to be more adaptable, concurrent, and >pertaining to object capability. This way, we can have a secure, >composable and parallelisable standard library! Um, and who are you volunteering to do all this work? i.e., "you and what army?" :) >Hope this all makes some kind of sense... your thoughts will be much >appreciated. Thanks! My thought is that you've just proposed several major PEPs that are already too late for Python 3.0 and would probably have been rejected or deferred anyway. I also think it's more likely that your ideas would find more interest/support with the PyPy project than with mainline Python, as some of them at least vaguely resemble some things they are working on, and/or would be easier to implement using PyPy object spaces. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
