#ifdef like question.

brueckd at tbye.com brueckd at tbye.com
Tue May 14 12:13:09 EDT 2002


On Tue, 14 May 2002, Roman Yakovenko wrote:

> Well, it's really dirty way to do it. 
> 
> Guys don't you think that we have some nice method to solve this problem ?
> 
> The problem: writing code using new futures( like generators, ...) 
> and code with the same functionality ( interface ) but using old methods.
> 
> There are a few solutions:

If you really need to do this, it's pretty clean to just ship both modules 
and have your package file (__init__.py) import the correct one at 
runtime.

That being said, the best solution IMO is also the simplest: don't do it.  
If you need to support older versions of Python, write the code so that it
uses features present in the older versions. If you need/want to use newer
features, include "requires Python 2.7" or whatever in some prominent
location in the docs/website and call it good. There may be some cases 
where you absolutely must support both, but unless it's a strict 
requirement it probably isn't worth the hassle.

Think of it this way: is the time and energy required to write, debug, and
maintain *two* versions of identical functionality really worth it or
would that energy be better spent elsewhere? If you've already built the
backwards compatible one, how much benefit will the new one really give
you? And if you need the new features to ensure correct functionality,
does providing a flaky/hacky backwards compatible workaround really help
your users? I'd wager that in most cases it's best for everyone involved 
if you just choose one and do it well.

-Dave






More information about the Python-list mailing list