<p>Hi Martin, bat files could be handled by g.extension. See also ticket to support compiling C modules on unix. (I cannot search it now.) Python modules on MS Windows are in the same situation as C modules on unix. Vaclav</p>
<div class="gmail_quote">On Aug 22, 2014 12:01 AM, "GRASS GIS" <<a href="mailto:trac@osgeo.org">trac@osgeo.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
#2150: Cannot call Python scripts from Python on MS Windows<br>
-------------------------------------------+--------------------------------<br>
Reporter: wenzeslaus | Owner: grass-dev@…<br>
Type: defect | Status: new<br>
Priority: blocker | Milestone: 7.0.0<br>
Component: Python | Version: svn-releasebranch64<br>
Keywords: packaging, MAXREPEAT, scripts | Platform: MSWindows 7<br>
Cpu: Unspecified |<br>
-------------------------------------------+--------------------------------<br>
<br>
Comment(by martinl):<br>
<br>
Replying to [comment:8 glynn]:<br>
<br>
> > My opinion is that requiring BAT file for Python scripts is much more<br>
worse solution that r57910.<br>
><br>
> Also, note that there's nothing special about .bat (or .cmd). The<br>
mechanism used for "executing" anything other than binary executables is<br>
the same, whether it's .bat or .py. If .bat works when .py doesn't, that<br>
indicates a fault in the Python installation.<br>
<br>
Update: as a result of never ending discussion I took liberty to add<br>
generation of bat files in r61136. The missing part is how to solve user<br>
python scripts.<br>
<br>
--<br>
Ticket URL: <<a href="http://trac.osgeo.org/grass/ticket/2150#comment:10" target="_blank">http://trac.osgeo.org/grass/ticket/2150#comment:10</a>><br>
GRASS GIS <<a href="http://grass.osgeo.org" target="_blank">http://grass.osgeo.org</a>><br>
<br>
</blockquote></div>