Re: [Gexiv2] Missing overrides ... better error message



On Wed, Aug 28, 2013 at 11:34 AM, Jim Nelson <jim yorba org> wrote:
Robert, can you speak to this point?

Hmmm, Matěj emailed me privately (and I responded to him privately)
before I saw that he also sent it to this list.

Here's my response:

On Wed, Aug 28, 2013 at 1:42 AM, Matěj Cepl <mcepl redhat com> wrote:
Would it be possible to add (somewhere?, where?) some better error
message than completely baffling

GObject.__init__() takes exactly 0 arguments (1 given)

I'm not sure how we could possibly change this. If I was going to change
the exception raised by a given function, i'd do that in the override file.
But the error here is that the override file is missing, which leaves us
with no way to have any control over what errors are raised!

You have to understand, without the overrides file, you are accessing raw C
API directly, without any filter or bindings. The only way to change its
behavior is in the C code itself. Best case, if you submitted a patch
upstream that allowed the GExiv2.Metadata object take an argument in it's
constructor, you could print a warning from C that says "this method
doesn't really take an argument, you just don't have your python overrides
installed properly". But I doubt that upstream would accept it, because a)
it breaks C API, and b) it prints an ugly warning about a
python-specific problem
from within C, which could strike any user of any language.

The overrides file is not optional for python, I'm not sure why so many
people packaging gexiv2 think that it can just be tucked into some optional
secondary package and then not include it by default. It's kind of
insulting, the way it takes my work and just sort of discards an enormously
important piece of it, and then expects everything to continue working
anyway. I mean, I guess I can appreciate not wanting a C/Vala library to
have a dependency on python, but anybody using GExiv2 in python is going to
want their own package to depend on the python support.


Of course, from this everybody understands that she should install
overrides :)

Yeah, sorry. When I said "clearly indicates" on that bug, I meant it was
clear *to me* ;-)

The reason it was so clear to me, is that the override is what defines that
__init__ takes an argument. The C constructor does not take any arguments;
so if the error says "takes 0 arguments", then you're clearly calling the C
constructor, not the __init__ that I wrote in the override.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]