On 28 December 2013 22:27, Steven D'Aprano <steve@pearwood.info> wrote:
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.
I used to be a fan of the "or" based variants, but I eventually went off the idea. My reasoning went as follows: 1. For a single file script, you're only doing the import once, so there's no repetition, and hence little to be gained from the more concise syntax (and the cost of a new thing for readers to learn) 2. For a multi file package or application, it's trivial to factor out the compatibility checking to a helper module, so there's *still* no need for repetition. A compatibility module also lets you build an adaptation layer if the APIs aren't *quite* the same (for example, RHEL5 has the ancient pre-simplejson JSON module, so naive "import json" code will mistakenly think it has the 2.6+ stdlib version - a helper module can detect oddball discrepancies like that one and work around them, but naive syntax would do the wrong thing if a similar situation arose again in the future). Essentially, the niche that the syntax variants can cover is too small to be worth making the already horrendously complex import statement syntax and semantics even *more* complicated, when you can either spell it out explicitly in the single file case, or use a helper module to centralise the selection logic in the multiple file case. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia