All Python extensions made using SWIG must be used with specific
versions of Python. Since most Python extensions are in fact made
using SWIG, this is hardly uncommon. You can verify it by going to the
Python home page and looking through the catalog of extensions.
Where Csound differs from other SWIG-based extensions, perhaps, is
that we do not currently produce multiple versions of the extension
modules targetted to different versions of Python. Feel free to
contribute this to Csound, if you think it important enough.
The SWIG approach has worked extremely well for us to date. It would
be possible to move to boost::python or to ctypes, but both would
involve considerably more work. I suspect the boost::python approach
also would be harder to build and maintain.
I have Csound working with Python 2.6 on Windows, and the next Windows
release will be targetted for Python 2.6.
Regards,
Mike
On 6/28/09, DavidW <
vip@...> wrote:
> On 28/06/2009, at 9:23 AM, victor wrote:
>
>> What do you mean? Should we move to Python 2.6?
>
>
> Sorry if I wasn't clear. I'm not saying anything different to what I
> was saying on the dev-list for a couple of years. Maybe the issue is
> still discussed there; I don't know, I stopped reading it some time ago.
>
> Python APIs are useful for different reasons, including compositional/
> sonification/exhibtion etc etc (*), and in such application, csound is
> just another API whose explicit purpose is the synthesis/processing of
> sound. Other extensions include interfaces to 3 or 4 different
> database types, fast multidimensional array processing, graphical
> output, GUI, network applications, etc etc for all of which developers
> maintain versions that use eggs or at least easy_install that compile/
> install dependent on the _users_ version of python (within some
> backwards-compatibility window).
>
> Csound python API is a library _extension_ of python so in the general-
> to-specific usage model outlined above, it makes sense to ensure it
> independent of (or as easily compilable for) any particular version of
> python. At the moment the interaction between csound and SCons seems
> to require some 'hand nursing' to produce an API for particular
> version of python and so if you want to integrate csound into your
> work you're restricted to the use of versions of python for which that
> nursing has been effected. Or if you're using an older version of
> python, you don't have access to the latest csound additions.
>
> IMO, that limitation is a debilitating one and limits the potential
> user base of csound; most (serious) python users (a considerably
> larger user base than that of csound) simply will not entertain using
> csound while that limitation applied. Thankfully there are other
> alternatives, which, while they may not be as comprehensive as csound,
> are not dependent in the manner described.
>
> So, in short my answer to
>
>> Should we move to Python 2.6?
>
>
> is that it doesn't matter. Most python users who maintain a body of
> code are probably already testing against v3.
> The solution must lie in the domain of generalising the build process.
>
> D.
>
> (*) Limiting music with computers to _sound_, will ensure it continues
> to suffer from the same problems that all Cartesian models do.
>
>
> ________________________________________________
> David Worrall.
> - Experimental Polymedia: worrall.avatar.com.au
> - Sonification: www.sonifiction.com.au
> - Education for Financial Independence: www.mindthemarkets.com.au
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email
sympa@... with body "unsubscribe
> csound"
>
--
Michael Gogins
Irreducible Productions
http://www.michael-gogins.comMichael dot Gogins at gmail dot com
------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel
