> 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.
Ah, wasn't suggesting dumping the unittest module. Just that tests in the "standard library" should be doctest-based as these are much nicer and more useful! > 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. I agree with your -1. Let me rephrase that as being able to use any character in a str for import as opposed to the current limited set in 2.x. I understand that python literals are much broader in 3.0, how does that impact import? > >* 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?" :) Well, all that code being added to PyPi and the ASPN Python cookbook ain't being done by imagination alone... ;p Seriously, with: a). clear 'lead by example' initial set of how modules should work (with the above mentioned feature sets) b). a provisional incentive model (say, via a gift economy model for all those who have contributed to the standard library) c). a simple hook in the importer which keeps track of modules/code is used, which is used to remunerate the army (if anyone ever contributes financially to it) ;p > 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 understood that issues relating to the standard library were still not fixed-in-stone for python 3.0? > 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. This is definitely true. But I want to see all this in Python 3.0... And, I don't see any of the changes proposed requiring any changes to the language.. besides the __subclasses__ and func_closure thing we discussed on python-dev. -- love, tav founder and ceo, esp metanational llp plex:espians/tav | [EMAIL PROTECTED] | +44 (0) 7809 569 369 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
