On Fri, Dec 27, 2013 at 12:59:48PM -0800, Andrew Barnert wrote:
On Dec 27, 2013, at 9:43, Ryan Gonzalez <rymg19@gmail.com> wrote:
I like that. I usually end up doing that with ElementTree:
try: from xml.etree import cElementTree as etree
Python 3 has already fixed that. You just import ElementTree and you get the C-accelerated version.
And the same is true for cPickle, etc.
Not if the C-accelerated version isn't available. Or perhaps there are two pure-Python modules with the same API, and you're not sure which is installed. This issue is bigger than just C-accelerators in the CPython standard library. It applies any time you have two or more alternatives with the same API, a preferred module and an fallback module. E.g. readline in the stdlib, versus pyreadline, a third-party Windows port. A point against this suggestion: the best syntactic sugar opens up new and successful idioms. List comps and decorators have been great successes. Being able to embed a list comp as an expression, instead of a for-loop as a statement, is a great win. This new syntax doesn't open up new idioms for writing code. It is purely sugar, and as such, it isn't such a compelling feature. On the other hand, I think it does simplify a very common use-case. I often use fallback modules with the same API, and if only this new syntax had been introduced back in Python 2.4 or 2.5 I would be using it all the time now. Unfortunately, most (but not all) of my code has to support 2.4 or 2.5, or at least 3.3, so the usefulness of new syntax is severely limited *right now*. But if this syntax were introduced into Python 3.5 (its surely too late for 3.4) I reckon I would be able to use it around Python 3.6 or 3.7. And of course those who won't need to support versions of Python prior to 3.5 could use it straight away. So don't think of this as something you are going to use. Think of this as an investment for future Python users who are starting with 3.5 and don't care about backwards compatibility with Python 3.3 and 3.4 (let alone older versions). On that basis, I'm going to vote: +1 on "import preferred or fallback as name". +0 on allowing "import module or None", to cover the idiom: try: import module except ImportError: module = None which may not be encouraged, but it is occasionally useful. -0 on "from preferred or fallback import name", simply because I'm not sure how to extend it to multiple names, so I'd rather leave it out. -1 on Amber's original suggestion "maybe import name", as the benefit is too little to justify introducing a new keyword. -- Steven