Modules that provide differing functionality amongst different Python versions...

[holger krekel]

On Sun, Apr 21, 2002 at 02:23:26PM -0400, Aahz wrote:
> In article <mailman.1019412399.4283.python-list at python.org>,
> holger krekel  <pyth at devel.trillke.net> wrote:
> >On Sun, Apr 21, 2002 at 01:35:09PM -0400, Aahz wrote:
> >> In article <304d20df.0204210629.3f2b4d58 at posting.google.com>,
> >> Allan Crooks <googlegroups at sixtyten.org> wrote:
> >>>
> >>>Another thought I've had is doing it by specifying, say for module
> >>>'x', having modules 'x_20', 'x_21', 'x_22', with x simply finding out
> >>>what versions of Python it is running on, and then compiling all
> >>>modules it can deal with, and then importing all objects into it's
> >>>namespace.
> >> 
> >> Yup.  But do it with a package.
> >
> >But doesn't this lead to lots of duplicated -hard to maintain-  code?
> 
> Depends.  You can certainly construct your package to use common code.
> But if you're truly set on using the idioms of each Python version to
> the full extent while still providing backwards compatibility, you're
> going to have a problem with code duplication.  Period.

Depends. You can certainly construct your code so that e.g.
it either uses generators or fully-constructed lists. Python supports 
a nice abstraction:

for item in func():
	whatever_you_do_to(item)

func() could return a list or be a generator, you never know :-)
It's probably no coincedence that generators and fully constructed
lists are often exchangeable for 1:n relations (e.g. directory-lists).

filter(somefilter, func()) # generator or list? don't care :-)

But if you are truly set on using incompatible constructs  
*everywhere* for the fun of it, you are going to have a problem
with code duplication :-)

	Holger