On Thu, Apr 29, 2004 at 12:00:26AM +0200, Lele Gaifax wrote:
> No, what I tried to prove and, due my total lack of time to devote to
> it, failed, is that I'm /quiet/ sure that, with much less effort in
> time and resources, Pyrex could let cmpilato (and me :) to actually
> think at an OO layer, and maybe trying more alternatives and choose
> the better one, rather than struggling with the swig way, of writing
> awful wrapper code.
>
> Pyrex makes it almost trivial to get that "direct layer", that's
> all. It does not prevent it, as I tried to show in my initial,
> somewhat snobbed, message that started this thread. It surely frees
> lot of time that one could spend on other good things, I guess :)
I find this difficult to believe. From looking at the Pyrex
documentation it looks like a different way of doing things. But I
don't buy the argument that it is necessarily easier. The problems just
happen to be different.
> Sorry Ben, but no again. It's not a matter of being more powerful for
> Perl than for Python. Current Perl bindings are in better shape than
> Python's only for the effort spent on them by various people, not
> because of swig. That effort is not easily/mechanically reflectible on
> the other languages. When swig arrived, it was more thought for
> wrapping *old* libraries in a snap, rather than producing something
> with an high quality interface.
Huh? That's not what I said. In fact I'd say my statement agreed with
you. Which is exactly why I suggest you spend your time working on the
Python interfaces...
While the work to make the direct interface to the C API in Python is
helpful with the Perl version, the Perl OO interface is obviously not
helpful to the Python people. From what I'm seeing with Pyrex you wrap
the C API with Pyrex and then write Python code on top of that to give
it an OO interface (or Pyrex code which is really just Python turned
into C using the Python API). The end result seems to be the same for
about the same amount of work and probably would even look almost
identical (as far as the code to provide the OO interface). So I'm
entirely unclear on how it's easier to get an OO interface.
> Admittedly my Perl knowledge faded away, so cannot speak for that, but
> for Python I *do* think that the one-to-one mirror cmpilato wanna base
> the nicer OO on, that swig should/will provide, is far easily
> reachable with Pyrex, and the final product would be a full fledged
> first class python module, with documentation et all, rather than an
> intricated marshal-in/marshal-out dance.
Python already *HAS* the "one-to-one mirror" done. There may be a few
places here and there where we've added stuff that Python hasn't kept up
with, but for the most part that's done.
What needs to be done is the stuff you'd be doing outside of Pyrex. The
OO front end to the "one-to-one" mirror.
Additionally, how does Pyrex suddenly jump you from "an intricated
marshal-in/marshal-out dance" to a "first class python module, with
documentation et all [sic]." You make Pyrex sound like a silver bullet.
But wouldn't you still have to write the documentation? How does using
Pyrex get this done any easier? And what are the other things that
Pyrex is supposedly magically getting done for us that make a first
class module?
> So I do know the effort swig ate you all.
What? I don't think SWIG has really been all that difficult. Even
after looking at the Pyrex documentation I don't think it solves the
time consuming and difficult problems with wrapping our API... Namely
handling things like thunking callbacks, which as far as I can tell
Pyrex is still going to require that you do.
> Ben> It has some advantages.
>
> Like to ear ones :)
I've gone over them several times... I'm not doing it again. Not to
mention all the work that's already been done. You're advocating
essentially starting over from scratch...
> Ben> I think your time would be better spent working on writing
> Ben> the OO layer on top of SWIG.
>
> I really doubt. Been there, done that. Lots of things are missing, and
> are difficult/annoying/error-prone to get done with swig and almost
> there-for-free with a reasonable timespan spent on Pyrexing the svn
> libraries.
Like what is missing? I can think of a few things that haven't been
done in the SWIG Python bindings, mostly because they're just flat out
difficult to wrap. I don't see Pyrex as solving those difficulties.
You keep ignoring is that the SWIG stuff is pretty much done. You could
write the OO layer entirely in Python. After reading through the Pyrex
documentation, achieving the OO stuff looks to be the same amount of
effort assuming that the Python bindings are complete... The things
that aren't done with the SWIG bindings could be done by someone else,
and probably done in less time that it'd take you to do all the Pyrex
work from scratch.
> Believe me, I'd spend the needed time to write a little parser for the
> very good svn headers to translate them into pyrex interfaces (doc et
> all!!), rather than throwing away my time on swig singularities.
So what you're saying is, you'll have to write a custom piece of
software in order to get Pyrex doing things for "free"? Sounds to me
like you're exagerating the ease at which you can do things. SWIG has
had a C pre processor for quite a while and it *STILL* has problems
parsing some C stuff.
In the ind I think you're saying that you can write a C pre processor
faster than you can work with SWIG. Which just seems flat out false
to me.
> I'm really out of time on other projects, so I cannot prove this
> (now). I'm really sorry, but that's it.
All of which is moot because you don't have the time to do something
which is so easy and "almost-for-free". Humm...
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 29 01:01:48 2004