Python bindings -noproxy flag

[Philipp von Weitershausen <ph...@weitershausen.de>]

Hello,

why is the -noproxy flag passed to SWIG when building the python 
bindings? This forces SWIG not to build shadow classes for structs.

I think that pointers and accessor functions are not something that 
python programmers want to get involved with, not even when they are 
using bindings to a C API. SWIG already has the feature of building 
classes which can even be subclassed to add new functionality. Why 
aren't we using that feature?

Phil


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Python bindings -noproxy flag

[cm...@collab.net]

Philipp von Weitershausen <ph...@weitershausen.de> writes:

> cmpilato@collab.net wrote:
> > This has been asked before, and I don't remember the answer indicating
> > that there was any really intentional reason for this decision.  If
> > removing the -noproxy make our bindings better, sell us on the idea,
> > and you can bet we won't object to implementing that improvement.
> 
> What do I need to list for you to "buy" it? ;)

Oh, I just figured you could make the change and demonstrate its
goodness.

> As a python programmer, I expect a more or less good object oriented
> design. I would like to be able to subclass existing classes in order
> to add functionality. I don't want to deal with C datatypes,
> especially not structs and their accessor functions. This is what SWIG
> can for us already and it is just a command line switch away.

+1.

> IMO, the next step could be to hide all the low-level stuff
> (e.g. pools). It would be nice to have a Client class, a WorkingCopy
> class a Repository class and so on instead of the
> svn_<module>_<action> functions. This could be done entirely in Python
> (at least I think so) and I would be willing to help on that part.

+1.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Python bindings -noproxy flag

[Philipp von Weitershausen <ph...@weitershausen.de>]

cmpilato@collab.net wrote:
> This has been asked before, and I don't remember the answer indicating
> that there was any really intentional reason for this decision.  If
> removing the -noproxy make our bindings better, sell us on the idea,
> and you can bet we won't object to implementing that improvement.

What do I need to list for you to "buy" it? ;) I can really only repeat 
myself:

As a python programmer, I expect a more or less good object oriented 
design. I would like to be able to subclass existing classes in order to 
add functionality. I don't want to deal with C datatypes, especially not 
structs and their accessor functions. This is what SWIG can for us 
already and it is just a command line switch away.

IMO, the next step could be to hide all the low-level stuff (e.g. 
pools). It would be nice to have a Client class, a WorkingCopy class a 
Repository class and so on instead of the svn_<module>_<action> 
functions. This could be done entirely in Python (at least I think so) 
and I would be willing to help on that part.

Maybe in the (far?) future, it might even be possible to provide your 
own implementations written in Python as a drop-in replacement for 
existing parts of the library. That'd be really cool.

Phil


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Python bindings -noproxy flag

[cm...@collab.net]

Philipp von Weitershausen <ph...@weitershausen.de> writes:

> Hello,
> 
> why is the -noproxy flag passed to SWIG when building the python
> bindings? This forces SWIG not to build shadow classes for structs.
> 
> I think that pointers and accessor functions are not something that
> python programmers want to get involved with, not even when they are
> using bindings to a C API. SWIG already has the feature of building
> classes which can even be subclassed to add new functionality. Why
> aren't we using that feature?

This has been asked before, and I don't remember the answer indicating
that there was any really intentional reason for this decision.  If
removing the -noproxy make our bindings better, sell us on the idea,
and you can bet we won't object to implementing that improvement.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org