Dear Group:<br><br>Okay, I'm sold. Type conversions should not be implicit. What's the neatest way to make them explicit?<br><br>I am initiating the <b>Vernon's Storm Programming Challenge</b><br><i><br></i>(The winner will receive immortal glory and a gift certificate for a Big Mac.)<br>
<br><i>challenge I<br><br></i>I have a new class, inspired by PEP 313, useful for movie copyright dates and major American football games.<br>It is a subclass of int and works like this:<br><br>>>> import roman<br>
>>> print roman.roman('II') + roman.roman('Vii')<br>IX<br>>>> roman.toRoman(52)<br>u'LII'<br>>>> roman.fromRoman('MCMXLXI')<br>1951<br>>>><br>>>> roman.toRoman('this is garbage')<br>
Traceback (most recent call last):<br> File "<stdin>", line 1, in <module><br> File "roman.py", line 97, in toRoman<br> n = int(N)<br>ValueError: invalid literal for int() with base 10: 'this is garbage'<br>
<br>In a sports database, I want to make a column 'superbowl' which gets and gives data of class 'roman'.<br><br>How do I implement it in storm?<br>--<br>Vernon Cole<br><br><div class="gmail_quote"><br>On Tue, Feb 17, 2009 at 2:11 AM, Stuart Bishop <span dir="ltr"><<a href="mailto:stuart@stuartbishop.net">stuart@stuartbishop.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Tue, Feb 17, 2009 at 2:18 AM, Jamu Kakar <<a href="mailto:jkakar@kakar.ca">jkakar@kakar.ca</a>> wrote:<br>
> Hi,<br>
><br>
> On Mon, Feb 16, 2009 at 7:03 PM, Ben Wilber <<a href="mailto:benwilber@gmail.com">benwilber@gmail.com</a>> wrote:<br>
>> This can, however, get overly complicated with complex types like<br>
>> datetimes and whatnot, but for something reasonably simple, like<br>
>> Unicode or Int, I feel defining the type once, in the model<br>
>> definition, and then trapping on impossible conversion exceptions<br>
>> should be sufficient. But you're right that this is something pretty<br>
>> easy to do outside Storm. In fact, I've started subclassing the Storm<br>
>> types to do the conversion as was suggested earlier, which is a pretty<br>
>> simple fix.<br>
><br>
> I'm on the "the default behaviour should not include automatic<br>
> coercion" side of the fence; however, I do think that many people<br>
> want what you want. I wonder about providing this as an optional<br>
> feature of the column types. For example, we could have a coerce<br>
> keyword:<br>
><br>
> id = Int(allow_none=False, coerce=True)<br>
><br>
> Another option would be to provide a global setting (or maybe even<br>
> per Store), something like:<br>
><br>
> storm.set_automatic_coercion(True)<br>
><br>
> or<br>
><br>
> store.set_automatic_coercion(True)<br>
><br>
> I think of those options, I like the coerce keyword option the best.<br>
> What do you think?<br>
<br>
</div>In most cases, coercion is just digging your hole deeper. If you have<br>
wired up the wrong form validation function to the wrong database<br>
column, I'd like to know now rather than when it ends up on production<br>
triggering exceptions from real world input. I can't imagine a useful<br>
case where I would want this, and the previous arguments just don't<br>
make sense to me. Coercion is sweeping potential bugs under the carpet<br>
(and even Int -> Unicode conversion can lead to data loss, such as<br>
loss of leading zeros, and needs to be trapped), and in many<br>
environments would lead to an increase in LOC since you have so many<br>
more cases to test. Even if a database column is being used to store<br>
multiple datatypes (eg. a key/type/value table), you still need to be<br>
explicit about what values can be stored because you need to ensure<br>
nothing gets stored that your application doesn't know how to cope<br>
with - you just end up with 'Dear <CustomerName at 0x123456>' or 'Dear<br>
False' because Storm happily coerced stuff to a Unicode string for<br>
you, or code that explodes on production because sometimes the browser<br>
sends data in an unexpected character set, and your byte string -><br>
Unicode conversion fails or worse you end up storing corrupt data.<br>
There would be more work involved proving that there are no data loss<br>
bugs introduced by the automatic coercion than just being explicit.<br>
<br>
A coerce argument might be useful in some cases, but I tend to think<br>
it should be a callable to actually do the coercion rather than an<br>
everything/nothing toggle. You could use it to convert byte strings to<br>
Unicode for instance if you know what the encoding will be or know you<br>
have to use a heuristic to guess.<br>
<br>
I do think Storm should remain Pythonic.<br>
<font color="#888888"><br>
--<br>
Stuart Bishop <<a href="mailto:stuart@stuartbishop.net">stuart@stuartbishop.net</a>><br>
<a href="http://www.stuartbishop.net/" target="_blank">http://www.stuartbishop.net/</a><br>
</font><div><div></div><div class="Wj3C7c"><br>
--<br>
storm mailing list<br>
<a href="mailto:storm@lists.canonical.com">storm@lists.canonical.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/storm" target="_blank">https://lists.ubuntu.com/mailman/listinfo/storm</a><br>
</div></div></blockquote></div><br>