I wonder if your perceived need for this isn't skewed by your working within the core?
Also, in 3.0 many of the use cases should go away -- e.g. cStringIO vs, StringIO, etc., as we switch the stdlib to having a single "public" name for an API which automatically replaces or augments itself with the accelerated C version if available. --Guido On Jan 2, 2008 5:19 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > The standard library, my personal code, third-party packages, and my > employer's code base are filled with examples of the following pattern: > > try: > import threading > except ImportError: > import dummy_threading as threading > > try: > import xml.etree.cElementTree as ET > except ImportError: > try: > import cElementTree as ET > except ImportError: > import elementtree.ElementTree as ET > > try: > from cStringIO import StringIO > except ImportError: > from StringIO import StringIO > > try: > import readline > except ImportError: > pass > > > How about a new, simpler syntax: > > * import threading or dummy_threading as threading > > * import xml.etree.CElementTree or cElementTree or elementree.ElementTree as > ET > > * from cStringIO or StringIO import StringIO > > * import readline or emptymodule > _______________________________________________ > 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/guido%40python.org > -- --Guido van Rossum (home page: http://www.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
