On 8/15/06, <b class="gmail_sendername">Collin Winter</b> <<a href="mailto:collinw@gmail.com">collinw@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>How exactly do they "deduce" what Bar is, just from the "from bar<br>import Bar" line? pychecker would have to import and compile the Bar<br>module first. What if being able to import bar depends on some import
<br>hooks that some other module (imported before bar) installed? I guess<br>you'd have to follow the entire import graph just to make sure. Oh,<br>and you'd have to end up running the module being analysed in case<br>*it* installs some import hooks -- or maybe it defines Bar itself.
</blockquote><div><br>The end-user and the type checker creator can negotiate the boundary between convenience and easy to parse syntax. At first the type checker creator might say that things must be in a very predictable form with no variants and no renames. Then they might do a bit more analysis and be able to handle renames. Then they might evolve towards whole-program analysis and be able to handle very complicated imports.
<br><br>Surely you know that decorators can also be renamed, imported, etc. Same with base classes (which are considered key to type checking). This is just how Python works. Where people need to use static subsets of Python (like RPython, or the "freeze" program or the compilable subset used by Jython) they just define the subset and move on. The languages' core behaviour is defined dynamically.
<br><br> Paul Prescod<br><br></div><br></div>