From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4f34febc0701042014p7e13c951gc20bd80f44aa44b6@mail.gmail.com> Date: Thu, 4 Jan 2007 20:14:59 -0800 From: "John Barham" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] python In-Reply-To: <13426df10701041431w2272898eu3b620dd2b33086ff@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <13426df10701041431w2272898eu3b620dd2b33086ff@mail.gmail.com> Topicbox-Message-UUID: fd020cba-ead1-11e9-9d60-3106f5b1d025 > One problem concerns extensions. PYthon loves .so files. Plan 9, > obviously, does not. > > Lots of tools are structured in a way that's going to be a real pain > in the ass to fix. Python doesn't do 'make'. what it does is a > standard python setup.py build type of thing... The consensus seems to be that Python's setuptools works well for relatively simple extensions on supported platforms, but beyond that you have to hack. > Either that or we finally get around to implementing loadable modules . Longer term that would be ideal, as you wouldn't have to rebuild Python itself for every C extension module you wanted to use. There's also the simplifying requirement that Python extension module foo.so must define an initialization function initfoo(). However, I think a bigger advantage to implementing dynamic module loading for Python on Plan 9 would be that you could then use the new "ctypes" foreign function library recently introduced w/ Python 2.5 which allows you to wrap C libraries in pure Python, dispensing w/ tedious boiler-plate wrapping C code--at the expense of some type-safety. ;) John