stdlib with its own release cycle ?
Hello, That's not my idea, it has been suggested by several people in the distutils discussions. But I'd like to bring it here because I couldn't find a clear answer or position on this subject in the lists archives (let me know if there's one). And depending on the answers, I might suggest it as a topic for the next language summit. What about having a different release cycle for the stdlib, and shipping Python in two distinct releases: - Python : core + stdlib - Python-Stdlib : stdlib The Python release would remain unchanged, but its cycle would be longer (as the moratorium seems to imply). stdlib would have a shorter release cycle (18 months?) allowing people to upgrade it without having to wait for the next full Python release. Each stdlib release would be compatible with a range of Python versions. Regards, Tarek
Tarek Ziadé <ziade.tarek@...> writes:
What about having a different release cycle for the stdlib, and shipping Python in two distinct releases:
- Python : core + stdlib - Python-Stdlib : stdlib
The Python release would remain unchanged, but its cycle would be longer (as the moratorium seems to imply).
I don't think the moratorium should imply any longer release cycle. Many improvements aren't of the kind that the moratorium aims at freezing. We could actually make the whole release cycle shorter, knowing that releases will be less disruptive. Regards Antoine.
Antoine Pitrou schrieb:
Tarek Ziadé <ziade.tarek@...> writes:
What about having a different release cycle for the stdlib, and shipping Python in two distinct releases:
- Python : core + stdlib - Python-Stdlib : stdlib
The Python release would remain unchanged, but its cycle would be longer (as the moratorium seems to imply).
I don't think the moratorium should imply any longer release cycle. Many improvements aren't of the kind that the moratorium aims at freezing. We could actually make the whole release cycle shorter, knowing that releases will be less disruptive.
Exactly. Since with the moratorium in effect, we are basically changing *nothing but* the stdlib, it has its own release cycle already :) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Sun, Oct 25, 2009 at 12:56 PM, Georg Brandl <g.brandl@gmx.net> wrote:
Antoine Pitrou schrieb:
Tarek Ziadé <ziade.tarek@...> writes:
What about having a different release cycle for the stdlib, and shipping Python in two distinct releases:
- Python : core + stdlib - Python-Stdlib : stdlib
The Python release would remain unchanged, but its cycle would be longer (as the moratorium seems to imply).
I don't think the moratorium should imply any longer release cycle. Many improvements aren't of the kind that the moratorium aims at freezing. We could actually make the whole release cycle shorter, knowing that releases will be less disruptive.
Exactly. Since with the moratorium in effect, we are basically changing *nothing but* the stdlib, it has its own release cycle already :)
Great then ! how long the release cycle should be then, in your opinion ? Tarek
Tarek Ziadé schrieb:
On Sun, Oct 25, 2009 at 12:56 PM, Georg Brandl <g.brandl-hi6Y0CQ0nG0@public.gmane.org> wrote:
Antoine Pitrou schrieb:
Tarek Ziadé <ziade.tarek@...> writes:
What about having a different release cycle for the stdlib, and shipping Python in two distinct releases:
- Python : core + stdlib - Python-Stdlib : stdlib
The Python release would remain unchanged, but its cycle would be longer (as the moratorium seems to imply).
I don't think the moratorium should imply any longer release cycle. Many improvements aren't of the kind that the moratorium aims at freezing. We could actually make the whole release cycle shorter, knowing that releases will be less disruptive.
Exactly. Since with the moratorium in effect, we are basically changing *nothing but* the stdlib, it has its own release cycle already :)
Great then !
how long the release cycle should be then, in your opinion ?
I'd say, less than the usual 18 months, but no shorter than 12 months. We need some time to accumulate new features, but with concentration on the stdlib, also make good changes available soon enough. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Tarek Ziadé <ziade.tarek@...> writes:
On Sun, Oct 25, 2009 at 12:56 PM, Georg Brandl <g.brandl@...> wrote:
Exactly. Since with the moratorium in effect, we are basically changing *nothing but* the stdlib, it has its own release cycle already :)
Great then !
how long the release cycle should be then, in your opinion ?
I think 12 months would be cool. Moreover, it's easy to compute :-) Antoine.
On Sun, Oct 25, 2009 at 10:39 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
how long the release cycle should be then, in your opinion ?
I think 12 months would be cool. Moreover, it's easy to compute :-)
There are very good reasons we currently have releases 18+ months apart (it wasn't always this way; others can explain). I don't think those reasons have gone stale or are void given the moratorium. -- --Guido van Rossum PS. My elbow needs a couple more weeks of rest. Limiting myself to ultra-short emails.
2009/10/26 Benjamin Peterson <benjamin@python.org>
Tarek Ziadé <ziade.tarek@...> writes:
how long the release cycle should be then, in your opinion ?
I like a year.
+1
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On 10/25/2009 12:56 PM, Georg Brandl wrote:
Antoine Pitrou schrieb:
Tarek Ziadé <ziade.tarek@...> writes:
What about having a different release cycle for the stdlib, and shipping Python in two distinct releases:
- Python : core + stdlib - Python-Stdlib : stdlib
The Python release would remain unchanged, but its cycle would be longer (as the moratorium seems to imply).
I don't think the moratorium should imply any longer release cycle. Many improvements aren't of the kind that the moratorium aims at freezing. We could actually make the whole release cycle shorter, knowing that releases will be less disruptive.
Exactly. Since with the moratorium in effect, we are basically changing *nothing but* the stdlib, it has its own release cycle already :)
Georg
As I had understood it thats not what the moratorium is about. The *language* (grammar, syntax) will not be changed. That doesn't freeze the interpreter at all. Even removing the GIL would not change the syntax (or semantics!) of the language, but it's definitely not just a stdlib change. -panzi
Mathias Panzenböck schrieb:
On 10/25/2009 12:56 PM, Georg Brandl wrote:
Antoine Pitrou schrieb:
Tarek Ziadé <ziade.tarek@...> writes:
What about having a different release cycle for the stdlib, and shipping Python in two distinct releases:
- Python : core + stdlib - Python-Stdlib : stdlib
The Python release would remain unchanged, but its cycle would be longer (as the moratorium seems to imply).
I don't think the moratorium should imply any longer release cycle. Many improvements aren't of the kind that the moratorium aims at freezing. We could actually make the whole release cycle shorter, knowing that releases will be less disruptive.
Exactly. Since with the moratorium in effect, we are basically changing *nothing but* the stdlib, it has its own release cycle already :)
As I had understood it thats not what the moratorium is about. The *language* (grammar, syntax) will not be changed. That doesn't freeze the interpreter at all. Even removing the GIL would not change the syntax (or semantics!) of the language, but it's definitely not just a stdlib change.
So, how many of those changes do you think will be done? As you say, they don't change any semantics, just maybe (hopefully) performance. Stdlib changes will therefore be most visible. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Sun, Oct 25, 2009 at 4:56 AM, Georg Brandl <g.brandl@gmx.net> wrote:
Exactly. Since with the moratorium in effect, we are basically changing *nothing but* the stdlib, it has its own release cycle already :)
Not true. There is much core work that can be done without changing the language definition (e.g. removing the GIL, speedups). Also, extension modules written in C presumably don't fall under the separate stdlib release but are excluded from the moratorium. That said a separate stdlib release has been asked for at the language summit and I am supportive. But it's link with the moratorium is minimal. -- --Guido van Rossum PS. My elbow needs a couple more weeks of rest. Limiting myself to ultra-short emails.
Guido van Rossum schrieb:
On Sun, Oct 25, 2009 at 4:56 AM, Georg Brandl <g.brandl@gmx.net> wrote:
Exactly. Since with the moratorium in effect, we are basically changing *nothing but* the stdlib, it has its own release cycle already :)
Not true. There is much core work that can be done without changing the language definition (e.g. removing the GIL, speedups). Also, extension modules written in C presumably don't fall under the separate stdlib release but are excluded from the moratorium.
I'd have counted them among the stdlib. You're of course right, other core work can and should be done, but it won't be as visible as new stdlib modules or improved APIs in there. Anyway, we'll probably get a better picture of what 3.2 will look like after the PEP is written and we have a rough release schedule. Before that it's moot to decide on a separate stdlib release. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Guido van Rossum schrieb:
That said a separate stdlib release has been asked for at the language summit and I am supportive. But it's link with the moratorium is minimal.
On Sun, Oct 25, 2009 at 6:26 PM, Georg Brandl <g.brandl@gmx.net> wrote:
Anyway, we'll probably get a better picture of what 3.2 will look like after the PEP is written and we have a rough release schedule. Before that it's moot to decide on a separate stdlib release.
I guess I'll wait and see then. :) Here's Distutils use case FYI. I don't know if it can be applied to other packages in the stdlib but.. : The work that is being done in Distutils is going to really speed up once the PEPs we are working on are over and hopefully accepted, and this package would benefit from a shorter cycle. The other idea would be to do extra standalone releases of Distutils, between two Python releases. I am currently doing nightly builds of the trunk that can be installed from 2.4 to 3.1 to make it easier for people to try out the current Distutils trunk. But it's just for testing purposes, because it's currently using a dirty .pth trick to shadow the existing distutils. Regards Tarek
On Sun, Oct 25, 2009 at 10:26 AM, Georg Brandl <g.brandl@gmx.net> wrote:
Guido van Rossum schrieb:
On Sun, Oct 25, 2009 at 4:56 AM, Georg Brandl <g.brandl@gmx.net> wrote:
Exactly. Since with the moratorium in effect, we are basically changing *nothing but* the stdlib, it has its own release cycle already :)
Not true. There is much core work that can be done without changing the language definition (e.g. removing the GIL, speedups). Also, extension modules written in C presumably don't fall under the separate stdlib release but are excluded from the moratorium.
I'd have counted them among the stdlib.
Hmm, but C extensions don't work with other implementations (at least not with Jython, IronPython, PyPy).
You're of course right, other core work can and should be done, but it won't be as visible as new stdlib modules or improved APIs in there.
Depends. Imagine Unladen Swallow merged in -- it would be huge from all kinds of perspectives (pro and con, I suppose) but wouldn't change the language at all.
Anyway, we'll probably get a better picture of what 3.2 will look like after the PEP is written and we have a rough release schedule. Before that it's moot to decide on a separate stdlib release.
Hm, I think the separate-stdlib-release idea needs separate discussion quite independent of the moratorium. -- --Guido van Rossum PS. My elbow needs a couple more weeks of rest. Limiting myself to ultra-short emails.
On Sun, Oct 25, 2009 at 16:06, Guido van Rossum <guido@python.org> wrote:
On Sun, Oct 25, 2009 at 10:26 AM, Georg Brandl <g.brandl@gmx.net> wrote:
Guido van Rossum schrieb:
On Sun, Oct 25, 2009 at 4:56 AM, Georg Brandl <g.brandl@gmx.net> wrote:
Exactly. Since with the moratorium in effect, we are basically changing *nothing but* the stdlib, it has its own release cycle already :)
Not true. There is much core work that can be done without changing the language definition (e.g. removing the GIL, speedups). Also, extension modules written in C presumably don't fall under the separate stdlib release but are excluded from the moratorium.
I'd have counted them among the stdlib.
Hmm, but C extensions don't work with other implementations (at least not with Jython, IronPython, PyPy).
You're of course right, other core work can and should be done, but it won't be as visible as new stdlib modules or improved APIs in there.
Depends. Imagine Unladen Swallow merged in -- it would be huge from all kinds of perspectives (pro and con, I suppose) but wouldn't change the language at all.
Anyway, we'll probably get a better picture of what 3.2 will look like after the PEP is written and we have a rough release schedule. Before that it's moot to decide on a separate stdlib release.
Hm, I think the separate-stdlib-release idea needs separate discussion quite independent of the moratorium.
This has been debated in the stdlib-sig (came up when we talked about argparse) if you want some viewpoints. It is definitely a separate discussion and I expect it will be brought up at the language summit. -Brett
2009/10/25 Guido van Rossum <guido@python.org>
On Sun, Oct 25, 2009 at 10:26 AM, Georg Brandl <g.brandl@gmx.net> wrote:
Guido van Rossum schrieb:
On Sun, Oct 25, 2009 at 4:56 AM, Georg Brandl <g.brandl@gmx.net> wrote:
Exactly. Since with the moratorium in effect, we are basically changing *nothing but* the stdlib, it has its own release cycle already :)
Not true. There is much core work that can be done without changing the language definition (e.g. removing the GIL, speedups). Also, extension modules written in C presumably don't fall under the separate stdlib release but are excluded from the moratorium.
I'd have counted them among the stdlib.
Hmm, but C extensions don't work with other implementations (at least not with Jython, IronPython, PyPy).
Well, you can use Python C extensions with Ironclad [1]. The maintainer hopes to port the core to Jython at some point as well. Michael Foord [1] http://code.google.com/p/ironclad/
You're of course right, other core work can and should be done, but it won't be as visible as new stdlib modules or improved APIs in there.
Depends. Imagine Unladen Swallow merged in -- it would be huge from all kinds of perspectives (pro and con, I suppose) but wouldn't change the language at all.
Anyway, we'll probably get a better picture of what 3.2 will look like after the PEP is written and we have a rough release schedule. Before that it's moot to decide on a separate stdlib release.
Hm, I think the separate-stdlib-release idea needs separate discussion quite independent of the moratorium.
-- --Guido van Rossum
PS. My elbow needs a couple more weeks of rest. Limiting myself to ultra-short emails. _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On Sun, Oct 25, 2009 at 4:38 PM, Michael Foord <fuzzyman@gmail.com> wrote:
Well, you can use Python C extensions with Ironclad [1]. The maintainer hopes to port the core to Jython at some point as well.
What do you personally think of Ironclad? And (separately) of those hopes?
Michael Foord
-- --Guido van Rossum PS. My elbow needs a couple more weeks of rest. Limiting myself to ultra-short emails.
2009/10/25 Guido van Rossum <guido@python.org>
On Sun, Oct 25, 2009 at 4:38 PM, Michael Foord <fuzzyman@gmail.com> wrote:
Well, you can use Python C extensions with Ironclad [1]. The maintainer hopes to port the core to Jython at some point as well.
What do you personally think of Ironclad? And (separately) of those hopes?
It seems like it ought to be an impossible task - reimplementing the Python C API for another platform. It actually runs surprisingly well (astonishingly) and I know of at least one bank in London now using it in production. The Ironclad implementation reuses the Python C source wherever possible in order to minimise the core that actually needs implementing. A *large* number of the Numpy and SciPy tests pass with it (~1000 of each last time I checked) and *generally* performance is pretty good. I'd like to see Ironclad in wider use. The hopes of the Ironclad maintainer to reimplement the core for Jython is certainly *plausible*, but it of course depends on him finding time in the future. Personally when I write IronPython code I try to avoid a dependency on C extension modules as it seems to me that the *point* of IronPython is to make use of the .NET framework (otherwise you might as well just use CPython). Where Ironclad is being used is where people want to interface existing Python systems to existing .NET systems and that makes a lot of sense (you'd rather avoid rewriting chunks of either if you can and Ironclad acts as a bridge). All the best, Michael
Michael Foord
-- --Guido van Rossum
PS. My elbow needs a couple more weeks of rest. Limiting myself to ultra-short emails.
On Sun, Oct 25, 2009 at 5:12 PM, Michael Foord <fuzzyman@gmail.com> wrote:
2009/10/25 Guido van Rossum <guido@python.org>
On Sun, Oct 25, 2009 at 4:38 PM, Michael Foord <fuzzyman@gmail.com> wrote:
Well, you can use Python C extensions with Ironclad [1]. The maintainer hopes to port the core to Jython at some point as well.
What do you personally think of Ironclad? And (separately) of those hopes?
It seems like it ought to be an impossible task - reimplementing the Python C API for another platform. It actually runs surprisingly well (astonishingly) and I know of at least one bank in London now using it in production. The Ironclad implementation reuses the Python C source wherever possible in order to minimise the core that actually needs implementing.
A *large* number of the Numpy and SciPy tests pass with it (~1000 of each last time I checked) and *generally* performance is pretty good. I'd like to see Ironclad in wider use.
The hopes of the Ironclad maintainer to reimplement the core for Jython is certainly *plausible*, but it of course depends on him finding time in the future.
Personally when I write IronPython code I try to avoid a dependency on C extension modules as it seems to me that the *point* of IronPython is to make use of the .NET framework (otherwise you might as well just use CPython). Where Ironclad is being used is where people want to interface existing Python systems to existing .NET systems and that makes a lot of sense (you'd rather avoid rewriting chunks of either if you can and Ironclad acts as a bridge).
Hm. In the Java world, there are many target environments where depending on C extensions would not fly at all, since the only commonality between platforms is the JVM interface. (And sometimes not even that -- e.g. Android uses a different VM to run Java.) I'm guessing that in the .NET world this is much less of an issue, since (a) the platform is more homogeneous and under control of Microsoft (Mono notwithstanding) and (b) .NET explicitly targets other languages (though it prefers "managed C++", it supports plain C++). Have I got this right? I see the prospects for an IronClad-like thing in the Java world as pretty slim because of this.
Michael
-- --Guido van Rossum PS. My elbow needs a couple more weeks of rest. Limiting myself to ultra-short emails.
On Sun, Oct 25, 2009 at 8:56 PM, Guido van Rossum <guido@python.org> wrote:
On Sun, Oct 25, 2009 at 5:12 PM, Michael Foord <fuzzyman@gmail.com> wrote:
2009/10/25 Guido van Rossum <guido@python.org>
On Sun, Oct 25, 2009 at 4:38 PM, Michael Foord <fuzzyman@gmail.com> wrote:
Well, you can use Python C extensions with Ironclad [1]. The maintainer hopes to port the core to Jython at some point as well.
What do you personally think of Ironclad? And (separately) of those hopes?
It seems like it ought to be an impossible task - reimplementing the Python C API for another platform. It actually runs surprisingly well (astonishingly) and I know of at least one bank in London now using it in production. The Ironclad implementation reuses the Python C source wherever possible in order to minimise the core that actually needs implementing.
A *large* number of the Numpy and SciPy tests pass with it (~1000 of each last time I checked) and *generally* performance is pretty good. I'd like to see Ironclad in wider use.
The hopes of the Ironclad maintainer to reimplement the core for Jython is certainly *plausible*, but it of course depends on him finding time in the future.
Personally when I write IronPython code I try to avoid a dependency on C extension modules as it seems to me that the *point* of IronPython is to make use of the .NET framework (otherwise you might as well just use CPython). Where Ironclad is being used is where people want to interface existing Python systems to existing .NET systems and that makes a lot of sense (you'd rather avoid rewriting chunks of either if you can and Ironclad acts as a bridge).
Hm. In the Java world, there are many target environments where depending on C extensions would not fly at all, since the only commonality between platforms is the JVM interface. (And sometimes not even that -- e.g. Android uses a different VM to run Java.) I'm guessing that in the .NET world this is much less of an issue, since (a) the platform is more homogeneous and under control of Microsoft (Mono notwithstanding) and (b) .NET explicitly targets other languages (though it prefers "managed C++", it supports plain C++). Have I got this right? I see the prospects for an IronClad-like thing in the Java world as pretty slim because of this.
Michael
You've always got the JNI. I wrote the better part of a system to wrap Android's Java libraries for Python using it last summer, and although I stopped when I had enough working to use the Android components I needed from Python, I think it would have been comparatively easy to finish the job. Geremy Condra
2009/10/26 Guido van Rossum <guido@python.org>
On Sun, Oct 25, 2009 at 5:12 PM, Michael Foord <fuzzyman@gmail.com> wrote:
2009/10/25 Guido van Rossum <guido@python.org>
On Sun, Oct 25, 2009 at 4:38 PM, Michael Foord <fuzzyman@gmail.com>
Well, you can use Python C extensions with Ironclad [1]. The
hopes to port the core to Jython at some point as well.
What do you personally think of Ironclad? And (separately) of those hopes?
It seems like it ought to be an impossible task - reimplementing the Python C API for another platform. It actually runs surprisingly well (astonishingly) and I know of at least one bank in London now using it in production. The Ironclad implementation reuses the Python C source wherever possible in order to minimise the core that actually needs implementing.
A *large* number of the Numpy and SciPy tests pass with it (~1000 of each last time I checked) and *generally* performance is pretty good. I'd like to see Ironclad in wider use.
The hopes of the Ironclad maintainer to reimplement the core for Jython is certainly *plausible*, but it of course depends on him finding time in
wrote: maintainer the
future.
Personally when I write IronPython code I try to avoid a dependency on C extension modules as it seems to me that the *point* of IronPython is to make use of the .NET framework (otherwise you might as well just use CPython). Where Ironclad is being used is where people want to interface existing Python systems to existing .NET systems and that makes a lot of sense (you'd rather avoid rewriting chunks of either if you can and Ironclad acts as a bridge).
Hm. In the Java world, there are many target environments where depending on C extensions would not fly at all, since the only commonality between platforms is the JVM interface. (And sometimes not even that -- e.g. Android uses a different VM to run Java.) I'm guessing that in the .NET world this is much less of an issue, since (a) the platform is more homogeneous and under control of Microsoft (Mono notwithstanding) and (b) .NET explicitly targets other languages (though it prefers "managed C++", it supports plain C++). Have I got this right? I see the prospects for an IronClad-like thing in the Java world as pretty slim because of this.
Hehe, you actually raise several points in that short email. I'll address them one by one and try not to ramble too much. Firstly, although you are correct that .NET supports a managed variant of C++ (that runs 'on .NET') and it is the same set of tools that you also use to compile native code (unmanaged C/C++) this has nothing to do with .NET. Python for Windows is compiled with the Visual C++ compiler but it doesn't run on .NET. .NET doesn't even use the MSVCRT that compiled native code links against - something that causes Ironclad 'difficulties' when managed and native code need to share file handles. Ironclad itself has binary compatibility with Python C extensions, they don't need to be recompiled. It uses the .NET FFI (P/Invoke) to work with these extensions and on the JVM would use its FFI. My understanding is that Android now allows native code, so if Dalvik has the same FFI APIs and you can compile the Python extensions for it *and* Jython runs on Dalvik (not currently the case I believe?) then it could work... The .NET framework, even leaving aside Mono, is also diverse. There are several versions of the .NET framework: .NET CE (Compact Edition) that runs on mobile devices and the XBox 360, CoreCLR that runs on Silverlight and an embedded version. There is also a Mono application called MonoTouch that compiles .NET code for the iPhone (using Ahead Of Time compilation to generate native code). The embedded version will never support IronPython. The compact edition of .NET currently lacks the System.Reflection.Emit (code generation APIs) that IronPython uses. You aren't supposed to use interpreters on the iPhone so likewise System.Reflection.Emit can't be compiled with MonoTouch. I mention them because the Microsoft dynamic languages team are looking at a cut down version of IronPython (with some of the more dynamic features restricted) that can run on .NET CE and could be compiled with MonoTouch. It is possible that Ironclad could work with this. The CoreCLR in Silverlight does run IronPython but because of the sandboxing you can't call into native code, so you can't use Ironclad in the browser. Despite the places where Ironclad doesn't work, *most* .NET code runs on desktops or servers using the standard .NET framework - and this is where Ironclad is used. Despite the variety of different JVMs this is an analogous situation and I don't see why a port wouldn't be just as useful. As for Mono; Ironclad *currently* only works on .NET and on Windows. This is because it was originally created by Resolver Systems who only develop for Windows. There was *some* work by Seo Sanghyeon to port Ironclad to Mono, and there is nothing about the techniques Ironclad uses that would prevent it working on Mono. (Seo got distracted and the work was uncompleted but we're looking for volunteers to pick up porting Ironclad to Mono.) All the best, Michael Foord
Michael
-- --Guido van Rossum
PS. My elbow needs a couple more weeks of rest. Limiting myself to ultra-short emails.
On Mon, Oct 26, 2009 at 2:47 AM, Michael Foord <fuzzyman@gmail.com> wrote:
Ironclad itself has binary compatibility with Python C extensions, they don't need to be recompiled. It uses the .NET FFI (P/Invoke) to work with these extensions and on the JVM would use its FFI.
Ok, but that assumes the C extensions are already compiled for CPython on that platform (presumably .NET). This sounds limiting, and hacky (need lots of faith in the DLL loader). I also assume that calls back into the CPython runtime are somehow intercepted and somewhat limited to what is reasonable to support in the .NET world -- unless you basically link all of CPython in and then you might as well just make RPCs to CPython...
My understanding is that Android now allows native code,
Theoretically, yes. I don't think it's a good use of the platform though, you get huge binaries, long startup times, and quite limited functionality. Check out "Android Scripting Environment".
so if Dalvik has the same FFI APIs and you can compile the Python extensions for it *and* Jython runs on Dalvik (not currently the case I believe?)
Not yet, and not easy (the bytecode generator would have to be retargeted and probably a bunch of unsupported Java features would have to be worked around). Phones are slow and small...
then it could work...
The .NET framework, even leaving aside Mono, is also diverse. There are several versions of the .NET framework: .NET CE (Compact Edition) that runs on mobile devices and the XBox 360, CoreCLR that runs on Silverlight and an embedded version. There is also a Mono application called MonoTouch that compiles .NET code for the iPhone (using Ahead Of Time compilation to generate native code).
How hard was it to get IronPython to work on all? How much of the libraries work on all? Does Ironclad work on all?
The embedded version will never support IronPython. The compact edition of .NET currently lacks the System.Reflection.Emit (code generation APIs) that IronPython uses. You aren't supposed to use interpreters on the iPhone so likewise System.Reflection.Emit can't be compiled with MonoTouch. I mention them because the Microsoft dynamic languages team are looking at a cut down version of IronPython (with some of the more dynamic features restricted) that can run on .NET CE and could be compiled with MonoTouch. It is possible that Ironclad could work with this.
Forget I even asked. :-)
The CoreCLR in Silverlight does run IronPython but because of the sandboxing you can't call into native code, so you can't use Ironclad in the browser.
Despite the places where Ironclad doesn't work, *most* .NET code runs on desktops or servers using the standard .NET framework - and this is where Ironclad is used. Despite the variety of different JVMs this is an analogous situation and I don't see why a port wouldn't be just as useful.
Why not just use CPython? At Google we mix Python and Java using RPCs intead of mixing runtimes. It works quite well.
As for Mono; Ironclad *currently* only works on .NET and on Windows. This is because it was originally created by Resolver Systems who only develop for Windows. There was *some* work by Seo Sanghyeon to port Ironclad to Mono, and there is nothing about the techniques Ironclad uses that would prevent it working on Mono. (Seo got distracted and the work was uncompleted but we're looking for volunteers to pick up porting Ironclad to Mono.)
-- --Guido van Rossum PS. My elbow needs a couple more weeks of rest. Limiting myself to ultra-short emails.
2009/10/26 Guido van Rossum <guido@python.org>
On Mon, Oct 26, 2009 at 2:47 AM, Michael Foord <fuzzyman@gmail.com> wrote:
Ironclad itself has binary compatibility with Python C extensions, they don't need to be recompiled. It uses the .NET FFI (P/Invoke) to work with these extensions and on the JVM would use its FFI.
Ok, but that assumes the C extensions are already compiled for CPython on that platform (presumably .NET).
It uses the standard compiled binaries for CPython on Windows. Binary compatibility - so no need to compile a special version, just use the same binaries you use for CPython.
This sounds limiting, and hacky (need lots of faith in the DLL loader).
It needs an *understanding* of the DLL loader sure. You seem to be relying a lot on faith these days (well - two emails today anyway).
I also assume that calls back into the CPython runtime are somehow intercepted and somewhat limited to what is reasonable to support in the .NET world -- unless you basically link all of CPython in and then you might as well just make RPCs to CPython...
The CPython API is implemented so that calls to the API go through our code. This works in both directions (C extensions calling back into Python and Python calling into C extensions). Where the Python source code has C API functions that just call other functions we can reuse a lot of the CPython implementation, yes. This C code is running natively - it is *not* running on .NET, but where we need the bridge we use the FFI. The API functions that, for example, create a new type create an IronPython type instead of a CPython type though. This is the whole raison d'etre of Ironclad. It isn't limiting, what it gives you is the ability to use existing code that depends on C extensions without having to write your own wrapper layer or use RPC. So far there has been very little that has proved impossible with this approach.
My understanding is that Android now allows native code,
Theoretically, yes. I don't think it's a good use of the platform though, you get huge binaries, long startup times, and quite limited functionality. Check out "Android Scripting Environment".
Right. *Most* Java code is not running on Android though (in the same way as most .NET code isn't running on .NET CE), so it could be useful if people wanted it.
so if Dalvik has the same FFI APIs and you can compile the Python extensions for it *and* Jython runs on Dalvik (not currently the case I believe?)
Not yet, and not easy (the bytecode generator would have to be retargeted and probably a bunch of unsupported Java features would have to be worked around).
Phones are slow and small...
A lot of modern phones have 500mhz ARM processors and 128Mbyte RAM. Python was running on desktop devices a lot slower and 'smaller' not very long ago. :-) [snip...]
The CoreCLR in Silverlight does run IronPython but because of the sandboxing you can't call into native code, so you can't use Ironclad in the browser.
Despite the places where Ironclad doesn't work, *most* .NET code runs on desktops or servers using the standard .NET framework - and this is where Ironclad is used. Despite the variety of different JVMs this is an analogous situation and I don't see why a port wouldn't be just as useful.
Why not just use CPython? At Google we mix Python and Java using RPCs intead of mixing runtimes. It works quite well.
The use case for Resolver Systems (who created the Ironclad project) was that having written a programmable spreadsheet (desktop application) written in IronPython we had a lot of customers who wanted to use Numpy with it. We could have told them to go away and write their own RPC layer. Instead we decided to solve the problem. :-) With the Ironclad compatibility layer C extensions can be used without having to write an RPC layer and the data marshalling that involves. It works well... Other architectures (multi-process and RPC) may be suitable to some problems but it is nice to have the choice. There are a couple of interesting aspects of Ironclad that might have wider applicability in the future. IronPython doesn't have a GIL and doesn't use reference counting for garbage collection, but Ironclad has to work with C extensions that use both. If (for example) Unladen Swallow were to (eventually) be successful in removing the GIL and moved away from reference counting then it would be possible to retain binary API (ABI) compatibility with extensions written for 'standard' CPython. The GIL is simply faked. IronPython code is not restricted by the GIL but only one code path into Ironclad can acquire the GIL at a time. For reference counting we have a hybrid system keeping 'bridge' objects alive whilst the C extension has a reference to them but they may or may not be in use from the IronPython side. All the best, Michael -- http://www.ironpythoninaction.com/
Michael Foord wrote:
If (for example) Unladen Swallow were to (eventually) be successful in removing the GIL and moved away from reference counting then it would be possible to retain binary API (ABI) compatibility with extensions written for 'standard' CPython.
The GIL is simply faked. IronPython code is not restricted by the GIL but only one code path into Ironclad can acquire the GIL at a time.
For reference counting we have a hybrid system keeping 'bridge' objects alive whilst the C extension has a reference to them but they may or may not be in use from the IronPython side.
Something I've long been curious about (but never even come close to having the time to research) is the idea of using CPython extensions with PyPy. It sounds like that would involve an effort in a similar vein to porting Ironclad to Jython (i.e. porting the back end to PyPy instead). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Mon, Oct 26, 2009 at 3:13 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Something I've long been curious about (but never even come close to having the time to research) is the idea of using CPython extensions with PyPy. It sounds like that would involve an effort in a similar vein to porting Ironclad to Jython (i.e. porting the back end to PyPy instead).
I'd love to see someone from PyPy comment on this too. IIUC they aren't particularly keen -- their approach so far has been based on porting existing C extensions to use ctypes, which they *do* support. -- --Guido van Rossum PS. My elbow needs a couple more weeks of rest. Limiting myself to ultra-short emails.
2009/10/26 Guido van Rossum <guido@python.org>
On Mon, Oct 26, 2009 at 3:13 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Something I've long been curious about (but never even come close to having the time to research) is the idea of using CPython extensions with PyPy. It sounds like that would involve an effort in a similar vein to porting Ironclad to Jython (i.e. porting the back end to PyPy instead).
I'd love to see someone from PyPy comment on this too. IIUC they aren't particularly keen -- their approach so far has been based on porting existing C extensions to use ctypes, which they *do* support.
Well, IronPython now has ctypes too (as of IronPython 2.6) - so porting C extensions to ctypes is still a better approach for cross implementation portability. Michael
-- --Guido van Rossum
PS. My elbow needs a couple more weeks of rest. Limiting myself to ultra-short emails. _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
Nick Coghlan <ncoghlan@...> writes:
Something I've long been curious about (but never even come close to having the time to research) is the idea of using CPython extensions with PyPy. It sounds like that would involve an effort in a similar vein to porting Ironclad to Jython (i.e. porting the back end to PyPy instead).
We say "it would be possible", but no one is really interested in doing the work which it would involve. At the moment, it's not even possible to have loadable RPython extension modules because of how the RPython translator works. Our answer right now, though, is that we want to eliminate the need for C extensions at all. ctypes can be used for binding to C libraries and our JIT can provide speed.
2009/10/26 Nick Coghlan <ncoghlan@gmail.com>
Michael Foord wrote:
If (for example) Unladen Swallow were to (eventually) be successful in removing the GIL and moved away from reference counting then it would be possible to retain binary API (ABI) compatibility with extensions written for 'standard' CPython.
The GIL is simply faked. IronPython code is not restricted by the GIL but only one code path into Ironclad can acquire the GIL at a time.
For reference counting we have a hybrid system keeping 'bridge' objects alive whilst the C extension has a reference to them but they may or may not be in use from the IronPython side.
Something I've long been curious about (but never even come close to having the time to research) is the idea of using CPython extensions with PyPy. It sounds like that would involve an effort in a similar vein to porting Ironclad to Jython (i.e. porting the back end to PyPy instead).
Porting the Ironclad core to RPython using the PyPy FFI would presumably be possible. Last time I spoke to the PyPy devs about it they said they had a different approach in mind that would give them source compatibility but not binary compatibility. I guess reinventing the wheel is the core motivation of PyPy so I guess they can be forgiven. ;-) Michael
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Mon, Oct 26, 2009 at 5:47 AM, Michael Foord <fuzzyman@gmail.com> wrote:
2009/10/26 Guido van Rossum <guido@python.org>
On Sun, Oct 25, 2009 at 5:12 PM, Michael Foord <fuzzyman@gmail.com> wrote:
2009/10/25 Guido van Rossum <guido@python.org>
On Sun, Oct 25, 2009 at 4:38 PM, Michael Foord <fuzzyman@gmail.com> wrote:
Well, you can use Python C extensions with Ironclad [1]. The maintainer hopes to port the core to Jython at some point as well.
What do you personally think of Ironclad? And (separately) of those hopes?
It seems like it ought to be an impossible task - reimplementing the Python C API for another platform. It actually runs surprisingly well (astonishingly) and I know of at least one bank in London now using it in production. The Ironclad implementation reuses the Python C source wherever possible in order to minimise the core that actually needs implementing.
A *large* number of the Numpy and SciPy tests pass with it (~1000 of each last time I checked) and *generally* performance is pretty good. I'd like to see Ironclad in wider use.
The hopes of the Ironclad maintainer to reimplement the core for Jython is certainly *plausible*, but it of course depends on him finding time in the future.
Personally when I write IronPython code I try to avoid a dependency on C extension modules as it seems to me that the *point* of IronPython is to make use of the .NET framework (otherwise you might as well just use CPython). Where Ironclad is being used is where people want to interface existing Python systems to existing .NET systems and that makes a lot of sense (you'd rather avoid rewriting chunks of either if you can and Ironclad acts as a bridge).
Hm. In the Java world, there are many target environments where depending on C extensions would not fly at all, since the only commonality between platforms is the JVM interface. (And sometimes not even that -- e.g. Android uses a different VM to run Java.) I'm guessing that in the .NET world this is much less of an issue, since (a) the platform is more homogeneous and under control of Microsoft (Mono notwithstanding) and (b) .NET explicitly targets other languages (though it prefers "managed C++", it supports plain C++). Have I got this right? I see the prospects for an IronClad-like thing in the Java world as pretty slim because of this.
Hehe, you actually raise several points in that short email. I'll address them one by one and try not to ramble too much.
Firstly, although you are correct that .NET supports a managed variant of C++ (that runs 'on .NET') and it is the same set of tools that you also use to compile native code (unmanaged C/C++) this has nothing to do with .NET. Python for Windows is compiled with the Visual C++ compiler but it doesn't run on .NET. .NET doesn't even use the MSVCRT that compiled native code links against - something that causes Ironclad 'difficulties' when managed and native code need to share file handles.
Ironclad itself has binary compatibility with Python C extensions, they don't need to be recompiled. It uses the .NET FFI (P/Invoke) to work with these extensions and on the JVM would use its FFI.
My understanding is that Android now allows native code, so if Dalvik has the same FFI APIs and you can compile the Python extensions for it *and* Jython runs on Dalvik (not currently the case I believe?) then it could work...
No need. Java has the Java Native Interface, which is supported in the Android Native Development Kit. Geremy Condra
On Mon, Oct 26, 2009 at 10:27 AM, geremy condra <debatem1@gmail.com> wrote:
No need. Java has the Java Native Interface, which is supported in the Android Native Development Kit.
If it's that easy why aren't more people developing Android apps using Jython? -- --Guido van Rossum PS. My elbow needs a couple more weeks of rest. Limiting myself to ultra-short emails.
On Mon, Oct 26, 2009 at 1:29 PM, Guido van Rossum <guido@python.org> wrote:
On Mon, Oct 26, 2009 at 10:27 AM, geremy condra <debatem1@gmail.com> wrote:
No need. Java has the Java Native Interface, which is supported in the Android Native Development Kit.
If it's that easy why aren't more people developing Android apps using Jython?
-- --Guido van Rossum
Because Jython doesn't run on dalvik- dalvik bytecode and normal java bytecode are quite different, and apparently porting Jython to dalvik would be quite the task in its own right. So far, there have been two solutions to this: the first is, as you mention, ASE, which works by exposing a small handful of convenience functions to scripting languages via JSON. As you point out, that's quite slow and limiting. Secondly, there's the approach that I took- simply wrap the most of the JNI in the CPython interface. It requires more work to get multiple language support- which was their goal in pushing ASE- but it's quite doable, and frankly if I knew enough about the JNI to make it happen somebody else has almost certainly had better luck. It took me a while to get as far as I did on the problem at least partially because of my unfamiliarity with both the JNI and with the CPython C API, but here's a (working) example of how you use it: Here’s the Java class: public class Sample { private boolean booleanMethod(boolean bool) { return !bool; } public int intMethod(int n) { return n+n; } } And here’s how you map it to Python: from java import Java @Java class Sample: '''Sample Java class implementation''' def __init__(self): self.java_init() def booleanMethod(truth: "Z") -> "Z": '''Returns the inverse of what was passed in.''' return self.java_booleanMethod(truth) def intMethod(x: "I") -> "I": '''Returns double the passed-in value''' return self.java_intMethod(x) And from then on you can use it just like a Python class, because it is. There are limitations- you can't pass arrays filled with arbitrary objects ATM- but if there's any interest in the project I could fill those gaps in the period of a few weeks. I can't make any quantitative evaluations of how quickly it runs- my main goal was not speed but getting full access- but I can say that feel-wise it was possible for a nontechnical friend to repeatedly identify whether a given app was using ASE or Javalin based solely on the speed at which they responded. Geremy Condra
2009/10/26 geremy condra <debatem1@gmail.com>
[snip...]
Firstly, although you are correct that .NET supports a managed variant of C++ (that runs 'on .NET') and it is the same set of tools that you also use to compile native code (unmanaged C/C++) this has nothing to do with .NET. Python for Windows is compiled with the Visual C++ compiler but it doesn't run on .NET. .NET doesn't even use the MSVCRT that compiled native code links against - something that causes Ironclad 'difficulties' when managed and native code need to share file handles.
Ironclad itself has binary compatibility with Python C extensions, they don't need to be recompiled. It uses the .NET FFI (P/Invoke) to work with these extensions and on the JVM would use its FFI.
My understanding is that Android now allows native code, so if Dalvik has the same FFI APIs and you can compile the Python extensions for it *and* Jython runs on Dalvik (not currently the case I believe?) then it could work...
No need. Java has the Java Native Interface, which is supported in the Android Native Development Kit.
No need for what? If you are using Jython *and* you want to use Python C extensions then something like Ironclad would be needed. If you aren't using Jython then no need - but there are lots of good reasons for *wanting* to use Jython. Michael
Geremy Condra
On Mon, Oct 26, 2009 at 2:07 PM, Michael Foord <fuzzyman@gmail.com> wrote:
2009/10/26 geremy condra <debatem1@gmail.com>
[snip...]
Firstly, although you are correct that .NET supports a managed variant of C++ (that runs 'on .NET') and it is the same set of tools that you also use to compile native code (unmanaged C/C++) this has nothing to do with .NET. Python for Windows is compiled with the Visual C++ compiler but it doesn't run on .NET. .NET doesn't even use the MSVCRT that compiled native code links against - something that causes Ironclad 'difficulties' when managed and native code need to share file handles.
Ironclad itself has binary compatibility with Python C extensions, they don't need to be recompiled. It uses the .NET FFI (P/Invoke) to work with these extensions and on the JVM would use its FFI.
My understanding is that Android now allows native code, so if Dalvik has the same FFI APIs and you can compile the Python extensions for it *and* Jython runs on Dalvik (not currently the case I believe?) then it could work...
No need. Java has the Java Native Interface, which is supported in the Android Native Development Kit.
No need for what? If you are using Jython *and* you want to use Python C extensions then something like Ironclad would be needed.
If you aren't using Jython then no need - but there are lots of good reasons for *wanting* to use Jython.
Michael
Sorry, I wasn't clear- there's no need to get Jython running on Android, since you can wrap the class libraries using JNI. Geremy Condra
On Mon, Oct 26, 2009 at 3:51 PM, geremy condra <debatem1@gmail.com> wrote:
Sorry, I wasn't clear- there's no need to get Jython running on Android, since you can wrap the class libraries using JNI.
So one would be running CPython and calling into the Android-specific Java library via JNI? That doesn't sound like a good use of the Android platform to me. -- --Guido van Rossum PS. My elbow needs a couple more weeks of rest. Limiting myself to ultra-short emails.
On Mon, Oct 26, 2009 at 7:00 PM, Guido van Rossum <guido@python.org> wrote:
On Mon, Oct 26, 2009 at 3:51 PM, geremy condra <debatem1@gmail.com> wrote:
Sorry, I wasn't clear- there's no need to get Jython running on Android, since you can wrap the class libraries using JNI.
So one would be running CPython and calling into the Android-specific Java library via JNI? That doesn't sound like a good use of the Android platform to me.
-- --Guido van Rossum
PS. My elbow needs a couple more weeks of rest. Limiting myself to ultra-short emails.
<shrugs> beats being stuck with ASE- which basically means not being able to make apps for Python, since you can't make .apk's with it- or trying to port Jython. If you have a better alternative, I'm all ears. Geremy Condra
2009/10/26 geremy condra <debatem1@gmail.com>
On Mon, Oct 26, 2009 at 2:07 PM, Michael Foord <fuzzyman@gmail.com> wrote:
2009/10/26 geremy condra <debatem1@gmail.com>
[snip...]
Firstly, although you are correct that .NET supports a managed variant of C++ (that runs 'on .NET') and it is the same set of tools that you
use to compile native code (unmanaged C/C++) this has nothing to do with .NET. Python for Windows is compiled with the Visual C++ compiler but it doesn't run on .NET. .NET doesn't even use the MSVCRT that compiled native code links against - something that causes Ironclad 'difficulties' when managed and native code need to share file handles.
Ironclad itself has binary compatibility with Python C extensions,
also they
don't need to be recompiled. It uses the .NET FFI (P/Invoke) to work with these extensions and on the JVM would use its FFI.
My understanding is that Android now allows native code, so if Dalvik has the same FFI APIs and you can compile the Python extensions for it *and* Jython runs on Dalvik (not currently the case I believe?) then it could work...
No need. Java has the Java Native Interface, which is supported in the Android Native Development Kit.
No need for what? If you are using Jython *and* you want to use Python C extensions then something like Ironclad would be needed.
If you aren't using Jython then no need - but there are lots of good reasons for *wanting* to use Jython.
Michael
Sorry, I wasn't clear- there's no need to get Jython running on Android, since you can wrap the class libraries using JNI.
There are all sorts of reasons to want to use Jython and being on a fundamentally Java oriented platform sounds like just about the best reason I can imagine. Michael
Geremy Condra
On Mon, Oct 26, 2009 at 4:08 PM, Michael Foord <fuzzyman@gmail.com> wrote:
There are all sorts of reasons to want to use Jython and being on a fundamentally Java oriented platform sounds like just about the best reason I can imagine.
Plus, Charlie made JRuby run on Android -- where's the competitive spirit? :) (http://blog.headius.com/2009/08/return-of-ruboto.html) -- Curt Hagenlocher curt@hagenlocher.org
On Mon, Oct 26, 2009 at 7:08 PM, Michael Foord <fuzzyman@gmail.com> wrote:
2009/10/26 geremy condra <debatem1@gmail.com>
On Mon, Oct 26, 2009 at 2:07 PM, Michael Foord <fuzzyman@gmail.com> wrote:
2009/10/26 geremy condra <debatem1@gmail.com>
[snip...]
Firstly, although you are correct that .NET supports a managed variant of C++ (that runs 'on .NET') and it is the same set of tools that you also use to compile native code (unmanaged C/C++) this has nothing to do with .NET. Python for Windows is compiled with the Visual C++ compiler but it doesn't run on .NET. .NET doesn't even use the MSVCRT that compiled native code links against - something that causes Ironclad 'difficulties' when managed and native code need to share file handles.
Ironclad itself has binary compatibility with Python C extensions, they don't need to be recompiled. It uses the .NET FFI (P/Invoke) to work with these extensions and on the JVM would use its FFI.
My understanding is that Android now allows native code, so if Dalvik has the same FFI APIs and you can compile the Python extensions for it *and* Jython runs on Dalvik (not currently the case I believe?) then it could work...
No need. Java has the Java Native Interface, which is supported in the Android Native Development Kit.
No need for what? If you are using Jython *and* you want to use Python C extensions then something like Ironclad would be needed.
If you aren't using Jython then no need - but there are lots of good reasons for *wanting* to use Jython.
Michael
Sorry, I wasn't clear- there's no need to get Jython running on Android, since you can wrap the class libraries using JNI.
There are all sorts of reasons to want to use Jython and being on a fundamentally Java oriented platform sounds like just about the best reason I can imagine.
Michael
But Jython doesn't run on Dalvik, so its kind of a nonissue. Geremy Condra
2009/10/26 geremy condra <debatem1@gmail.com>
On Mon, Oct 26, 2009 at 7:08 PM, Michael Foord <fuzzyman@gmail.com> wrote:
2009/10/26 geremy condra <debatem1@gmail.com>
On Mon, Oct 26, 2009 at 2:07 PM, Michael Foord <fuzzyman@gmail.com>
2009/10/26 geremy condra <debatem1@gmail.com>
[snip...]
Firstly, although you are correct that .NET supports a managed variant of C++ (that runs 'on .NET') and it is the same set of tools that you also use to compile native code (unmanaged C/C++) this has nothing to do
with
.NET. Python for Windows is compiled with the Visual C++ compiler but it doesn't run on .NET. .NET doesn't even use the MSVCRT that compiled native code links against - something that causes Ironclad 'difficulties' when managed and native code need to share file handles.
Ironclad itself has binary compatibility with Python C extensions, they don't need to be recompiled. It uses the .NET FFI (P/Invoke) to work with these extensions and on the JVM would use its FFI.
My understanding is that Android now allows native code, so if Dalvik has the same FFI APIs and you can compile the Python extensions for it *and* Jython runs on Dalvik (not currently the case I believe?) then it could work...
No need. Java has the Java Native Interface, which is supported in
wrote: the
Android Native Development Kit.
No need for what? If you are using Jython *and* you want to use Python C extensions then something like Ironclad would be needed.
If you aren't using Jython then no need - but there are lots of good reasons for *wanting* to use Jython.
Michael
Sorry, I wasn't clear- there's no need to get Jython running on Android, since you can wrap the class libraries using JNI.
There are all sorts of reasons to want to use Jython and being on a fundamentally Java oriented platform sounds like just about the best reason I can imagine.
Michael
But Jython doesn't run on Dalvik, so its kind of a nonissue.
I was responding to your comment that there was no need to port it. If there is a reason to use it then there is a reason to port it. Michael
Geremy Condra
On Mon, Oct 26, 2009 at 7:23 PM, Michael Foord <fuzzyman@gmail.com> wrote:
2009/10/26 geremy condra <debatem1@gmail.com>
On Mon, Oct 26, 2009 at 7:08 PM, Michael Foord <fuzzyman@gmail.com> wrote:
2009/10/26 geremy condra <debatem1@gmail.com>
On Mon, Oct 26, 2009 at 2:07 PM, Michael Foord <fuzzyman@gmail.com> wrote:
2009/10/26 geremy condra <debatem1@gmail.com>
[snip...] > Firstly, although you are correct that .NET supports a managed > variant > of > C++ (that runs 'on .NET') and it is the same set of tools that you > also > use > to compile native code (unmanaged C/C++) this has nothing to do > with > .NET. > Python for Windows is compiled with the Visual C++ compiler but it > doesn't > run on .NET. .NET doesn't even use the MSVCRT that compiled native > code > links against - something that causes Ironclad 'difficulties' when > managed > and native code need to share file handles. > > Ironclad itself has binary compatibility with Python C extensions, > they > don't need to be recompiled. It uses the .NET FFI (P/Invoke) to > work > with > these extensions and on the JVM would use its FFI. > > My understanding is that Android now allows native code, so if > Dalvik > has > the same FFI APIs and you can compile the Python extensions for it > *and* > Jython runs on Dalvik (not currently the case I believe?) then it > could > work... >
No need. Java has the Java Native Interface, which is supported in the Android Native Development Kit.
No need for what? If you are using Jython *and* you want to use Python C extensions then something like Ironclad would be needed.
If you aren't using Jython then no need - but there are lots of good reasons for *wanting* to use Jython.
Michael
Sorry, I wasn't clear- there's no need to get Jython running on Android, since you can wrap the class libraries using JNI.
There are all sorts of reasons to want to use Jython and being on a fundamentally Java oriented platform sounds like just about the best reason I can imagine.
Michael
But Jython doesn't run on Dalvik, so its kind of a nonissue.
I was responding to your comment that there was no need to port it. If there is a reason to use it then there is a reason to port it.
Michael
Unfortunately, according to people who know Jython much better than I, the amount of work involved would be analogous to the effort involved to write Jython in the first place. Since I doubt strongly that I have either the technical or political skills to develop and maintain my own Python implementation, I prefer the escape hatch. Your mileage apparently does vary. Geremy Condra
On Tue, Oct 27, 2009 at 12:31 AM, geremy condra <debatem1@gmail.com> wrote:
Unfortunately, according to people who know Jython much better than I, the amount of work involved would be analogous to the effort involved to write Jython in the first place. Since I doubt strongly that I have either the technical or political skills to develop and maintain my own Python implementation, I prefer the escape hatch. Your mileage apparently does vary.
Sure... it is true that making Jython run on Dalvik/Android is a big task, but saying that it requires the same amount of work as reimplementing Jython from scratch is a huge overstatement. It is true that it would not be as easy as it was for Charles to get JRuby to run on Dalvik/Android. JRuby has always had an interpreter and then JITs to Java bytecode while Jython compiles all code to Java bytecode immediately when loaded. There are efforts underway to make future versions of Jython run on Android, but just like the core CPython developers most of us are doing Jython as a side project, so it takes time. Very early experiments are looking promising though, but there is still a long way to go. If someone sent me an Android dev. phone I might get more motivated to focus my efforts in that direction... ;) Cheers, Tobias
On Tue, Oct 27, 2009 at 2:24 AM, Tobias Ivarsson <thobes@gmail.com> wrote:
On Tue, Oct 27, 2009 at 12:31 AM, geremy condra <debatem1@gmail.com> wrote:
Unfortunately, according to people who know Jython much better than I, the amount of work involved would be analogous to the effort involved to write Jython in the first place. Since I doubt strongly that I have either the technical or political skills to develop and maintain my own Python implementation, I prefer the escape hatch. Your mileage apparently does vary.
Sure... it is true that making Jython run on Dalvik/Android is a big task, but saying that it requires the same amount of work as reimplementing Jython from scratch is a huge overstatement. It is true that it would not be as easy as it was for Charles to get JRuby to run on Dalvik/Android. JRuby has always had an interpreter and then JITs to Java bytecode while Jython compiles all code to Java bytecode immediately when loaded.
I can pretty much guarantee that you know more about what you're talking about than I do. Having said that- several highly skilled developers, each certainly more experienced with both Java and Jython than myself, have tried their hands at this and nearly a year later none have succeeded. My project took me- a guy who hasn't touched Java, let alone the JNI, in nearly a decade- less than 8 weeks of intermittent effort. Sure, it's closer to what ctypes does than what Jython does, but working is working, and I'll take that. Plus it let me work in Python 3, which I prefer.
There are efforts underway to make future versions of Jython run on Android, but just like the core CPython developers most of us are doing Jython as a side project, so it takes time. Very early experiments are looking promising though, but there is still a long way to go.
If someone sent me an Android dev. phone I might get more motivated to focus my efforts in that direction... ;)
I can send you a shiny new emulator ;) Geremy Condra
On Sun, Oct 25, 2009 at 11:12:25AM +0100, Tarek Ziadé wrote:
What about having a different release cycle for the stdlib, and shipping Python in two distinct releases:
- Python : core + stdlib - Python-Stdlib : stdlib
-1 on this idea. This would make things complicated, which is against the zen of python. :) I see the discussion on smaller release cycle in the thread, that should be fine.. -- Senthil "There is no distinctly American criminal class except Congress." -- Mark Twain
participants (14)
-
Antoine Pitrou -
Benjamin Peterson -
Brett Cannon -
Curt Hagenlocher -
Georg Brandl -
geremy condra -
Guido van Rossum -
Jesse Noller -
Mathias Panzenböck -
Michael Foord -
Nick Coghlan -
Senthil Kumaran -
Tarek Ziadé -
Tobias Ivarsson