Dear Group:<br><br>Okay, I&#39;m sold. Type conversions should not be implicit. What&#39;s the neatest way to make them explicit?<br><br>I am initiating the <b>Vernon&#39;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>&gt;&gt;&gt; import roman<br>
&gt;&gt;&gt; print roman.roman(&#39;II&#39;) + roman.roman(&#39;Vii&#39;)<br>IX<br>&gt;&gt;&gt; roman.toRoman(52)<br>u&#39;LII&#39;<br>&gt;&gt;&gt; roman.fromRoman(&#39;MCMXLXI&#39;)<br>1951<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; roman.toRoman(&#39;this is garbage&#39;)<br>
Traceback (most recent call last):<br>&nbsp; File &quot;&lt;stdin&gt;&quot;, line 1, in &lt;module&gt;<br>&nbsp; File &quot;roman.py&quot;, line 97, in toRoman<br>&nbsp;&nbsp;&nbsp; n = int(N)<br>ValueError: invalid literal for int() with base 10: &#39;this is garbage&#39;<br>
<br>In a sports database, I want to make a column &#39;superbowl&#39; which gets and gives data of class &#39;roman&#39;.<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">&lt;<a href="mailto:stuart@stuartbishop.net">stuart@stuartbishop.net</a>&gt;</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 &lt;<a href="mailto:jkakar@kakar.ca">jkakar@kakar.ca</a>&gt; wrote:<br>

&gt; Hi,<br>
&gt;<br>
&gt; On Mon, Feb 16, 2009 at 7:03 PM, Ben Wilber &lt;<a href="mailto:benwilber@gmail.com">benwilber@gmail.com</a>&gt; wrote:<br>
&gt;&gt; This can, however, get overly complicated with complex types like<br>
&gt;&gt; datetimes and whatnot, but for something reasonably simple, like<br>
&gt;&gt; Unicode or Int, I feel defining the type once, in the model<br>
&gt;&gt; definition, and then trapping on impossible conversion exceptions<br>
&gt;&gt; should be sufficient. &nbsp;But you&#39;re right that this is something pretty<br>
&gt;&gt; easy to do outside Storm. &nbsp;In fact, I&#39;ve started subclassing the Storm<br>
&gt;&gt; types to do the conversion as was suggested earlier, which is a pretty<br>
&gt;&gt; simple fix.<br>
&gt;<br>
&gt; I&#39;m on the &quot;the default behaviour should not include automatic<br>
&gt; coercion&quot; side of the fence; however, I do think that many people<br>
&gt; want what you want. &nbsp;I wonder about providing this as an optional<br>
&gt; feature of the column types. &nbsp;For example, we could have a coerce<br>
&gt; keyword:<br>
&gt;<br>
&gt; id = Int(allow_none=False, coerce=True)<br>
&gt;<br>
&gt; Another option would be to provide a global setting (or maybe even<br>
&gt; per Store), something like:<br>
&gt;<br>
&gt; storm.set_automatic_coercion(True)<br>
&gt;<br>
&gt; or<br>
&gt;<br>
&gt; store.set_automatic_coercion(True)<br>
&gt;<br>
&gt; I think of those options, I like the coerce keyword option the best.<br>
&gt; 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&#39;d like to know now rather than when it ends up on production<br>
triggering exceptions from real world input. I can&#39;t imagine a useful<br>
case where I would want this, and the previous arguments just don&#39;t<br>
make sense to me. Coercion is sweeping potential bugs under the carpet<br>
(and even Int -&gt; 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&#39;t know how to cope<br>
with - you just end up with &#39;Dear &lt;CustomerName at 0x123456&gt;&#39; or &#39;Dear<br>
False&#39; 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 -&gt;<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 &lt;<a href="mailto:stuart@stuartbishop.net">stuart@stuartbishop.net</a>&gt;<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>