<p>On Aug 12, 2012 12:56 PM, &quot;PJ Eby&quot; &lt;<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>&gt; wrote:<br>
&gt; I&#39;m not sure if this is directly related or not, but making this<br>
&gt; mechanism support custom compilation for new filename suffixes would<br>
&gt; be nice, especially for various e.g. HTML/XML templating systems that<br>
&gt; compile to Python or bytecode.<br>
&gt;<br>
&gt; Specifically, having a way to add a new source suffix (e.g. &quot;.kid&quot;,<br>
&gt; &quot;.zpt&quot;, etc.) and a matching compilation function, such that it&#39;s<br>
&gt; automatically picked up for compilation by both the filesystem and zip<br>
&gt; importers would be awesome.  It&#39;d also allow for DSLs and syntax<br>
&gt; experiments using alternative filename extensions.</p>
<p>+1</p>
<p>I&#39;m hacking around this right now for a project I&#39;m working on.  I definitely do this through the import system.  Inserting a look-alike path hook and monkeypatching the cached path entry finders is not difficult, but certainly fragile and less than ideal.</p>

<p>Consequently I&#39;ve been looking into simple and not-so-simple solutions to making it easier to add new suffixes to be handled.  The source/pyc-to-code-to-module path during imports is so prevalent and critical that it may benefit from its own model.  This is similar to how the path-based import subsystem has its own special-case model.  Or source-based imports just need better special-casing in the path-based import subsystem.  Perhaps just adding and using sys.source_suffixes as a mapping of suffixes to loader classes.</p>

<p>-eric</p>