Alexey Neyman wrote on Tue, Oct 07, 2014 at 17:27:09 -0700:
> I have encountered a problem with Subversion's Python bindings. For example,
> the following simple program does not work:
Which version of the bindings? trunk?
> Am I correct in assuming that the division of a single 'pool' argument
> into distinct 'result_pool' and 'scratch_pool' is rather recent change
> and the bindings were not updated for that?
The first instances are a few years old (1.6.0 svn_wc.h has dual pools).
New instances of dual pools happen when we create an entirely new public
API, or when we rev a single-pool API (i.e., generally, a pre-1.6 API),
in which case we make the revved API use dual pools.
> Given all that, I could think of two approaches to fixing this issue.
>
> 1. Hackish, but simple.
>
> Change the call signature of the functions receiving one or two pool
> arguments: make them always receive a single argument for any pools
> it may have, which may be either None (meaning "use application pool"),
> a pool object (which will be used for both the result and scratch
> allocations) or a (result_pool, scratch_pool) tuple.
>
> This approach has two obvious drawbacks: first, it changes the
> number of arguments on the existing interfaces (but this may not
> be a bad thing, actually, given that it makes the breakage more
> explicit - rather than subtly using the scratch pool as described above).
> Second, it makes the argument lists for functions taking two pool
> arguments not match their C counterparts. E.g., svn_stream_open_readonly
> would be invoked as:
>
> // C
> res = svn_stream_open_readonly(&stream, "path",
> result_pool, scratch_pool);
>
> # Python
> stream = core.svn_stream_open_readonly("path", \
> (result_pool, scratch_pool))
You said you had two approaches, but you only list one?
Daniel
(I don't have time to digest your mail fully right now, although I get
the big picture.)
Received on 2014-10-08 09:57:24 CEST