On Friday 15 April 2011 15:10:35 Eli Stevens (Gmail) wrote: > On Fri, Apr 15, 2011 at 7:10 AM, Hugo Parente Lima > > <[email protected]> wrote: > > On Thursday 14 April 2011 21:39:14 Eli Stevens (Gmail) wrote: > >> 1. Consistent behavior across platforms (windows, OSX, etc.). > > > > This exists right now. > > I don't have direct evidence to the contrary, but one of my coworkers > was doing dev on OSX and he claimed that bools were round-tripping > cleanly for him. Given the behavior of ints on windows, that doesn't > surprise me (there is obviously some sort of type checking code going > on). > > >> 2. Clean roundtripping behavior (silently taking False and turning it > >> into u'false' -- a true value in python! -- is very dangerous). I'd > >> rather get a ValueError when trying to set the value than have it get > >> silently coerced to a string like that. > > > > You need to understand that the problem isn't in PySide itself, the > > problem is in Qt that stores every type as string in QSettings no matter > > if it's a bool, a int, etc.. > > Two things: > > 1. "Every type as a string" is not true; windows round-trips ints > cleanly (it sets registry entries for ints as REG_DWORD). See below. > 2. I am not suggesting that Qt try and round-trip all possible types. > I want types that *are not* supported to be rejected with a TypeError > (I said ValueError before, but that's incorrect). I agree that > sending in a string that looks like a float and getting a float back > is just as bad as sending in a bool and getting a string back. > > Under windows, this code produces the following output the first time > the program is run (ie. empty registry): > > v = self.settings.value('example', False) > print >>sys.stderr, type(v), repr(v) > > self.settings.setValue('example', False) > v = self.settings.value('example', 'none set') > print >>sys.stderr, type(v), repr(v) > > self.settings.setValue('example', 0) > v = self.settings.value('example', 'none set') > print >>sys.stderr, type(v), repr(v) > > <type 'bool'> False > <type 'unicode'> u'false' > <type 'int'> 0 > > The second time the program is run (ie. 'example' is set as REG_DWORD > = 0 due to the prior invocation): > > <type 'int'> 0 > <type 'unicode'> u'false' > <type 'int'> 0
You are using the windows registry as backend, if you use the .ini files as
backend you will notice the same behavior on both platform, as there's no
windows registry backend on Linux =].
As you can see the guy who wrote the Windows registry backend did the right
thing regarding to integers, but the bad thing regarding to bool values that
is returning strings instead of a QVariant of bool.
> >> 3. Consistent behavior between the program invocation where the
> >> setting was set, and the invocation where it is read. In my case, the
> >> errors didn't appear until the *second* time I ran the program.
> >
> > If you want to catch the errors at compile time you are using the wrong
> > tool, think about C++, Java or C#.
>
> The issue I encountered had has nothing to do with compile time.
>
> When my program runs the *first* time on a particular machine (ie.
> empty registry), the program works fine, due to the settings API not
> coercing the default argument of the settings.value call (ie. the
> False in the first line of code above) to what would actually be
> returned if that argument had been set. The <type 'bool'> False
> should never be returned, even if the key was empty. It should have
> either been <type 'unicode'> u'false' or raise a TypeError (I'd prefer
> the TypeError). On the second invocation, the False from before gets
> returned as u'false' and things start breaking (things only breaking
> on the second invocation is a unit testing nightmare, BTW ;).
We just re-pass to Python what we get from C++, no special treatment is done
on QSettings functions, if it returns a QVariant(0) we return int(0), if it
return QVariant("0") we return str("0"), nothing more.
> >> 4. Consistency with similar API calls from C++.
> >
> > C++ have QVariants and QStrings, PySide and PyQt (API2) not, and IMO back
> > with QVariant and QStrings would be a huge step backwards, the Python
> > code without those classes are much more simpler and ease to read and
> > write.
>
> I was probably unclear with this. I meant "if C++ only supports
> strings, then PySide should probably only support strings too, but 1,
> 2 and 3 are more important, so if you have to chose, break
> compatibility with C++." TBH, I like being able to round-trip ints in
> addition to strings, and would rather keep that ability than lose it
> just because the C++ side can't (I have no idea if C++ can round-trip
> ints or not).
1, 2 and 3 are directly linked to the fact that the QSettings API returns
wrong QVariant, but as when in C++ you always need to call toInt(), toBool(),
etc... this wrong QVariant's doesn't matter for C++ programmers, but if much
important to Python programmers as this toInt(), toFloat() is done
automagically by the binding based on QVariant::type().
> >> 5. Consistency with similar API calls from PyQt.
> >
> > This exists right now, if you use PyQt API2 you will get the unicodes as
> > well.
>
> Cool. This is last on the list from my PoV, since the consistency and
> correctness issues in 2 and 3 above are more important than strict
> backwards compatibility to me. Obviously, I'm just a user, so my
> opinion doesn't carry as much weight as if I were in a position to
> contribute patches, I just wanted to make sure my position was clearly
> expressed (it seemed like a lot of what I was trying to say wasn't
> being understood the way I intended; apologies if I was unclear).
Yes, your opinion is import and I understand that the current state isn't
perfect, I'm just saying that as the problem is in another layer (Qt) we have
just a limited amount of options to deal with the problem and those options
aren't backwards compatible.
> Thanks,
> Eli
--
Hugo Parente Lima
INdT - Instituto Nokia de Tecnologia
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ PySide mailing list [email protected] http://lists.pyside.org/listinfo/pyside
