Modules that provide differing functionality amongst different Python versions...
holger krekel
pyth at devel.trillke.net
Sun Apr 21 14:49:20 EDT 2002
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
More information about the Python-list
mailing list