[PyKDE] Re: PyKDE Digest, Vol 6, Issue 5

[Phil Thompson]

> It looks like a clarification of C++ is in order.
>>>
>>> I would expect that one can pass a Python int as well as a SIP-4.2
>>> enum
>>> argument into an enum parameter of a function wrapped by SIP (a C++
>>> function with a C++ enum parameter accepts C++ int arguments).
>
> That is incorrect.  C++ will NOT accept an int when a function has an
> enum parameter.  However, if the function takes an int it WILL allow an
> enum.  This is because C++ will convert and enum into an int, but not
> an int into an enum.  This is part of its type safety features.
>
>
>> Ok, I've had second thoughts about this - the idiom of oring enum
>> values is
>> too common. Tonight's SIP snapshot will allow an integer whereever an
>> enum is
>> expected. I can still get QListBox.setColumnMode() to work properly,
>> which
>> was the original intent of the change.
>>
> The 'or'ing together of enums to form an argument to a function is
> common, but if you look, the function signature takes an 'int' and not
> the enum.  When this is done, the enum is just being used as a symbolic
> constant and its type is usually irrelevant.

Hmm. When I tried a few of the PyQt examples I was getting errors - I'll
look again and pay a bit more attention to the messages.

> So what may be needed is a way to explicitly coerce a python 'int' into
> an enum just like it is possible to cast an int into an enum in C++
> (say a class method called 'intToEnum').  The explicit coercion would
> be a known 'dangerous thing to do' and if it failed, would be easy to
> find just by searching to code for the appropriate member function
> call.

You can do that with the snapshot, just pass the int as the only argument
to the enum type object.

> If you do allow all enums to be replaced automatically by ints, you are
> opening a very large number of qt undefined run time errors that could
> have been caught by the python type checking of the arguments used.

That behaviour is the current (SIP v4.1.1) behaviour so the relaxation I
was talking about means going back to the current behaviour. I want to
tighten up the type checking but don't want to break existing (reasonably
well behaved) applications.

Phil