On 02/05/2012 06:20 AM, Gregory Szorc wrote: > --- > bindings/python/clang/cindex.py | 8 ++++++++ > bindings/python/tests/cindex/test_type.py | 3 +++ > 2 files changed, 11 insertions(+), 0 deletions(-) > > > 0007-Implement-Type.argument_types-as-a-convenience-gener.patch > > > diff --git a/bindings/python/clang/cindex.py b/bindings/python/clang/cindex.py > index 4b25b03..bdcb716 100644 > --- a/bindings/python/clang/cindex.py > +++ b/bindings/python/clang/cindex.py > @@ -1139,16 +1139,24 @@ class Type(Structure): > return TypeKind.from_id(self._kind_id) > > @property > def arguments_count(self): > """Retrieve the number of non-variadic arguments for this function > type.""" > assert self.kind == TypeKind.FUNCTIONPROTO > return Type_get_num_arg_types(self) > > + @property > + def argument_types(self): > + """A generator of Type instances corresponding to the arguments for > + this function type.""" > + > + for i in range(0, self.arguments_count): > + yield self.get_arg_type(i)
And here we are. There is the python style iterator, that I was looking for in the previous patch. I must admit I am not super fluent in python best practices. You implement the iterator here with a generator. Other parts of these bindings such as TranslationUnit.diagnostics define an iterator (DiagIterator). What is main difference between them? For me it seems, with the DiagIterator we can directly use tu.diagnostics[0], which does not seem to be possible with the generator. Also for a generator we need to define a list explicitly. However, a generator may have other benefits. I am currently not sure which way we want to go, but I think we should use the same approach for all instances of this pattern. What do you think? Tobi _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
