As an alternative to an explicit assert, you may consider creating a decorator, e.g.<br><br>@enforce_type(inputNumber = Number)<br>def myfunc(inputNumber):<br>    do_stuff()<br><br>That way, it separates the type checking from the main body of code, and enforce_type could generate an appropriate detailed error message like &quot;myfunc expected inputNumber to be of type &#39;Number&#39; but was passed &#39;str&#39;&quot; which is nicer than just an assert. You could also easily demote it to a warning rather than an exception without changing all of your code (e.g. type enforcement only for debugging), although you might miss it if the method just stores the argument and the type error doesn&#39;t happen until much later, which is one argument for early typechecking.<br>

<br>Python 3.0 supports function annotations, which allows you to annotate function parameters with arbitrary objects including type objects (although it doesn&#39;t assign any special meaning to them), which would allow you to do something like:<br>

<br>@enforce_types<br>def myfunc(inputNumber: Number):<br>    do_stuff()<br><br>Note that numbers.Number (which is a superclass of the standard number types like int and float) is only available in Python 2.6+.<br>
<br>For non-numeric/non-string types though, you have to be more careful -- for example it&#39;s not uncommon for people to pass around dictionary-like objects that implement the usual x[&quot;key&quot;] protocol but aren&#39;t actually dictionaries. And file-like objects are enshrined in Python&#39;s API.<br>

<br>Python 2.6+ has the concept of Abstract Base Classes to allow type-checking to ensure an object implements a particular interface. It seems a little inconsistent though -- if you implement __iter__ on a random class MyClass then isinstance(MyClass(), collections.Iterable) returns True. However, if you try to implement the collections.Mapping ABC, simply implementing the methods __getitem__, __iter__, and __len__ is insufficient; isinstance(MyClass(), collections.Mapping) will return False.<br>
<br>In that case, you have to make MyClass subclass collections.Mapping, or use collections.Mapping.register(MyClass). This is OK if you control all the code, since you can just make sure all your dictionary-like objects inherit from the right ABC, but probably too strict for open-source library code where most people expect to pass an object that looks like a dictionary and have the duck typing just work.<br>
<br>You could potentially work around this in the type-checking decorator by, if the initial type check fails, iterate over the __abstractmethods__ property of the the required class and make sure all the necessary methods exist.<br>
<br>For your own user-defined classes which don&#39;t have a well-defined protocol like the collection ABCs though, it&#39;s probably more trouble than it&#39;s worth to define an explicit interface, in which case you might as well just stick to duck typing.<br>

<br> - Jason<br><br><div class="gmail_quote">On Thu, Oct 7, 2010 at 9:22 PM, Seth Friedman <span dir="ltr">&lt;<a href="mailto:sfseth@gmail.com" target="_blank">sfseth@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

Hi Mark,<div><br></div><div>Thanks for your response.</div><div><br></div><div>I can&#39;t quite wrap my head around your argument.  I don&#39;t think one or two lines per input is a lot of / too much time gatekeeping input variables.   Philisophically I think I see your point, I&#39;m trying to impose some rigidity in a domain that doesn&#39;t like it.  But there are lots of other values that python brings - it seems extreme to go to a different super-verbose language just for type-checking.  Not to mention that I don&#39;t trust those other languages to actually do it for me as well as python&#39;s assert(isinstance...) style - Java for instance strikes me as a prime candidate for false-negative type checking, they&#39;ve got a lot of subtle type variations.  </div>


<div><br></div><div>Is something like assert(isinstance(inputNumber,isActuallyANumberWeExpected)) really that cumbersome, aside from my long variable names?  The biggest examples I can think of are the distinctions between number and string of number, and list of numbers, which seem like totally legit &quot;how far does this function need to go&quot; question, asserting what is expected seems to illuminate rather than confuse.  </div>


<div><br></div><div>I mean, what&#39;s wrong with code asserting that what it got passed was what was expected?  If there&#39;s blind faith that stuff will just work beneath the scenes, ok, but when i *know* it won&#39;t, why not fail there, and explicitly?   If I write a function that can be called from python code or command line, I might get a string of a number or an int, and I will probably forget 6 months from now what I wrote the code to handle, without some kind of prompt.  The closer that prompt is to the disconnect, the better. <br>


<br></div><div>~seth</div><div><div></div><div><div><br><div class="gmail_quote">On Thu, Oct 7, 2010 at 8:20 PM, Mark Voorhies <span dir="ltr">&lt;<a href="mailto:mvoorhie@yahoo.com" target="_blank">mvoorhie@yahoo.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>On Thursday, October 07, 2010 07:32:18 pm Seth Friedman wrote:<br>
&gt; Hi Baypiggies,<br>
&gt;<br>
&gt; I&#39;ve encountered, a couple of times now, a sort of categorical &quot;dont do<br>
&gt; typechecking&quot; attitude on various blog posts and I haven&#39;t seen rationale to<br>
&gt; back it up.   Enough that I&#39;m now curious: what&#39;s the deal?<br>
&gt;<br>
&gt; So I put the question to you all, typechecking: good or bad thing?  Or<br>
&gt; pointless philosophical debate?<br>
<br>
</div>The lack of type signatures in function declarations are in line with &quot;Python<br>
as a rapid prototyping language&quot; -- if you&#39;re spending a lot of lines on &quot;gatekeeping&quot;<br>
a function&#39;s arguments, you might be better off in a language that does that<br>
work for you (e.g., Java, C++, ...).  There is a similar argument for not putting<br>
a lot of work into enforcing private variables in Python.<br>
<br>
That said, I don&#39;t have a strong opinion on this, and I&#39;ve heard the &quot;traits&quot; system<br>
in the Enthought Python Distribution recommended as a way to assert more<br>
control over the types that a function accepts.<br>
<font color="#888888"><br>
--Mark<br>
</font></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Baypiggies mailing list<br>
<a href="mailto:Baypiggies@python.org" target="_blank">Baypiggies@python.org</a><br>
To change your subscription options or unsubscribe:<br>
<a href="http://mail.python.org/mailman/listinfo/baypiggies" target="_blank">http://mail.python.org/mailman/listinfo/baypiggies</a><br></blockquote></div><br>