Hi Martin, Thanks for your update. It looks a bit complicated to me, but I've tested your changes, and it is seems to work! Let's go with this, even though I'm a bit skeptical to the limitations incurred.
Also, I've just opened a pull request with python 3 support that I worked on yesterday. https://github.com/strongswan/strongswan/pull/10 Cheers, Björn 2015-03-09 12:42 GMT+01:00 Martin Willi <[email protected]>: > Hi Björn, > > Thanks for reviewing these changes. > > > Nice start on the README. I took a moment to make the python part a bit > > more "pythonic", and pushed it to a branch on github: > > Thanks for the fixes, I've squashed them into the associated commits in > my branch. > > > I've taken a look at your code changes. I definitely agree that > > implicit error checking is nicer, and it will make the experience of > > using the library much smoother. There is a problem with your > > implementation however, you are discarding any errors for commands that > > require event streaming > > Correct, I've tried to address this with [1]. > > > While generators is a good idea for response streaming, it is not a great > > fit here. The current implementation works on the assumption that the > > generator is exhausted before another command starts. There is no way to > > guarantee this, as the user may draw elements from the generator as > he/she > > wishes. > > While I agree at some point, IMHO this is how generators in Python work. > The user should call call close() on it, either implicitly by breaking > from the iteration loop, or explicitly when manually iterating using > next(). > > Ideally, if the user does so we would unsubscribe from the events, and > prematurely return from the associated command. However, this is > currently not supported in vici at the daemon side, but we might extend > that in the future. > Instead, I'm just stopping calling yield once a GeneratorExit exception > gets raised. This makes sure the protocol stays in sync, but stops > returning results to the caller. This is implemented with [2]. > > > >>> g = s.list_certs() > > >>> msg = next(g) > > >>> print s.version() > > While this example still fails, the following should work as expected: > > >>> g = s.list_certs() > >>> msg = next(g) > >>> g.close() > >>> print s.version() > > I think with these changes, the advantages we get with the generator > approach at least compensate for the disadvantages, given that most > users iterate using "for" loops. > > Best regards > Martin > > [1]http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=be353005 > [2]http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=165603b5 > >
_______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
