[cfe-commits] [PATCH] Implement Type.argument_types as a convenience generator

[Tobias Grosser]

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