Hi, Greg,
Von: Greg Stein [mailto:gstein_at_gmail.com]
> On Aug 11, 2011 2:37 AM, "Markus Schaber" <m.schaber_at_3s-software.com>
wrote:
> > Von: Greg Stein [mailto:gstein_at_gmail.com]
> > ...
> > > With the prior constructions:
> > >
> > > open(foo).read()
> > > open(foo, 'w').write(bar)
> >
> > Constructs like this never worked reliable in alternative python
implementations.
> Yes. I do understand this thought, but the bindings simply are not
intended for anything but CPython. If they somehow work for the other
implementations, then I'd be completely surprised.
Bindings generating C gluecode are very unlikely to work for most
alternative implementations (maybe PyPy, Stackless or unladen swallow
with a small amount of work).
But I was told that the "future" of the python subversion binding lies
in cTypes, and IronPython has a working cTypes implementation now.
> > And now, as IronPython has a working cTypes implementation, maybe
that is the way to provide subversion support for IronPython.
> There is some experimental work using ctypesgen-based bindings. I did
a small amount of work on them a couple years ago, but it could use more
work.
> That would definitely be interesting work if it could make svn
available to IronPython.
Yes. Currently, I see the following ways:
0) Make the python interpreter compatible to the bindings
(-) Not possible with most implementations. (Not even cPython 3 is
compatible to cPython 2).
1) Simply access SharpSVN via IronPython.
(+) Works "as is".
(-) Incompatible to the official bindings (thus no existing code will
work.)
(-) The bindings are not really pythonic.
(-) Windows only, does not work on Linux or MacOS with Mono or
DotGnu.
(-) Limited to the subset of the API SharpSVN is exposing.
2) Re-implement the current API of the official bindings on top of
SharpSVN
(?) Could be done in IronPython or any .NET language.
(-) Lot of cumbersome work.
(-) Compatibility to the existing bindings may be impossible without
changes to SharpSVN.
(-) Windows only, does not work on Linux or MacOS with Mono or
DotGnu.
(-) Duplicates work to the official python bindings.
(-) Needs manual updating whenever Subversion gets new APIs.
(-) Unlikely to ever be part of the official Subversion distribution,
as SharpSVN cannot be built with free (beer) tools.
3) Manually re-implement a new glue layer in Python with cTypes
(-) Lot of cumbersome work.
(-) Duplicates work to the official python bindings.
(-) Needs manual updating whenever Subversion gets new APIs.
(+) Cross platform.
(+) Will support all python implementations providing working cTypes
implemenations (including Python 3).
(+) Will help to find bugs in aforementioned cTypes implementations.
(?) Maybe could provide a Binding for other .NET languages. Those
would need to carry IronPython and provide dynamic dispatching, however.
(?) Maybe we can maintain compatibility to existing bindings.
(-) Maybe not as efficient as the current C-based bindings.
4) Manually re-implement a new glue layer in C# with p/invoke
(-) Lot of cumbersome work.
(-) Duplicates work to the official python bindings.
(-) Needs manual updating whenever Subversion gets new APIs.
(+) Cross platform.
(?) Maybe could provide a Binding for other .NET languages
(alternative to SharpSVN).
(-) Would not help other alternative Python implementations.
(?) Maybe we can maintain compatibility to existing bindings.
5) Generate a glue code layer in C#
(-) AFAICS, the C# support of swig is not good enough for this yet.
(-) Unlikely to be part of the official Subversion distribution (C#
compiler needed).
(+) Cross platform.
(?) Maybe we could maintain compatibility to existing bindings.
(?) Maybe could provide a Binding for other .NET languages
(alternative to SharpSVN).
(-) Would not help other alternative Python implementations.
(+) Provides additional bindings
6) Bring the cTypes based bindings "up to par", and ensure they work
with IronPython.
(+) Should be less work than 2) and 3), as code generation is used,
and the beginnings already exist.
(?) Maybe we can maintain compatibility to existing bindings.
(?) Maybe they could replace the original bindings as "official"
ones.
(+) Due to code generation, staying "up to date" to new Subversion
APIs should be only a minor effort.
(+) Will support all python implementations providing working cTypes
implemenations (including Python 3).
(+) Will help to find bugs in aforementioned cTypes implementations.
(+) Cross platform.
(-) Maybe not as efficient as the current C-based bindings.
So it seems that the cTypes idea is the most beneficial one.
Best regards
Markus Schaber
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 |
Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects:
http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Received on 2011-08-11 14:11:34 CEST