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
>> 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 ;).
>> 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).
>> 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).
Thanks,
Eli
_______________________________________________
PySide mailing list
[email protected]
http://lists.pyside.org/listinfo/pyside
