Should Python Projects Support IronPython and Jython?
The maintainers of the Spring Framework for Python (Spring Python) wonder how much of a priority it is to have compatibility with platforms other than CPython. In other words, should they support IronPython and Jython - and if so what should they do about their C extension dependencies?
This question sparks a good discussion and is relevant to many other Python projects and applications:
"One of the topics on my mind recently, as we consider refactoring the core container, is how we ensure that when we introduce internal dependencies, such as possibly the Amara libraries for XML processing, what secondary constraints we might be introducing."
"For example, Amara represents a very pythonic and therefore simple to read and use approach to developing XML processing, such as our very own XML application configuration parsers. So from that perspective, things are very attractive. But then you ask the question, "can I run this on another python platform, such as IronPython and Jython?" and things get more constraining."
"However, my question is "is this important, in this case?" It's a general question for the Spring Python community really. Should we attempt to support the execution of SP applications on other platforms than CPython?"
"My feelings right now are that it is unlikely that a Spring Python application developer would expect to take their entire application as is and expect to run it on a different platform, such as .NET or Jython in the JVM. If I was going to do that, I would want to take advantage of the bits and pieces that are there in the .NET and Java worlds, and that would mean a port. It's also unlikely that I would necessarily get a business requirement to shift platforms like that... but I'm open to arguments there."
"My take is that Spring.NET provides Spring for the .NET community. Spring Java, well, it does the same for the Java community. Spring Python is doing the same for the Python community. The programming model and approach is portable, but it's not expected that the actual codebase is. Think of this as the concepts are the same, but exactly how you implement them would take full advantage of the platform you are on."
"So is this fair? This is where I need the community to chime in. Are my assumptions here wrong? Is there a defined need, special to the Python community, to come up with a framework that is truly portable at the implementation level, or is the goal really to create a framework that helps us use Spring concepts in the Python world. It's a BIG question, because it informs many of the core containers development choices, hence I thought it was time to get it out there for everyone to have their say."
This question sparks a good discussion and is relevant to many other Python projects and applications:
"One of the topics on my mind recently, as we consider refactoring the core container, is how we ensure that when we introduce internal dependencies, such as possibly the Amara libraries for XML processing, what secondary constraints we might be introducing."
"For example, Amara represents a very pythonic and therefore simple to read and use approach to developing XML processing, such as our very own XML application configuration parsers. So from that perspective, things are very attractive. But then you ask the question, "can I run this on another python platform, such as IronPython and Jython?" and things get more constraining."
"However, my question is "is this important, in this case?" It's a general question for the Spring Python community really. Should we attempt to support the execution of SP applications on other platforms than CPython?"
"My feelings right now are that it is unlikely that a Spring Python application developer would expect to take their entire application as is and expect to run it on a different platform, such as .NET or Jython in the JVM. If I was going to do that, I would want to take advantage of the bits and pieces that are there in the .NET and Java worlds, and that would mean a port. It's also unlikely that I would necessarily get a business requirement to shift platforms like that... but I'm open to arguments there."
"My take is that Spring.NET provides Spring for the .NET community. Spring Java, well, it does the same for the Java community. Spring Python is doing the same for the Python community. The programming model and approach is portable, but it's not expected that the actual codebase is. Think of this as the concepts are the same, but exactly how you implement them would take full advantage of the platform you are on."
"So is this fair? This is where I need the community to chime in. Are my assumptions here wrong? Is there a defined need, special to the Python community, to come up with a framework that is truly portable at the implementation level, or is the goal really to create a framework that helps us use Spring concepts in the Python world. It's a BIG question, because it informs many of the core containers development choices, hence I thought it was time to get it out there for everyone to have their say."
While I think it would be great for projects to strive for cross-implementation compatibility, I don't believe that it necessarily be the top priority. If they have some snazzy module that solves a problem perfectly for them, but it is tied to the JVM, CLR, or its a C extension, then it only makes sense to stick with what suites them.
ReplyDeleteAlso, each platform has many strengths and weaknesses that would lend to the decision of which to use.
Over all, I would hope that each of the implementations work with each other in some way to try to ensure that there are low barriers to entry by providing API compatible modules that actually wrap the platforms native objects. The Jython group is working very hard at this and I've been very impressed with their latest beta.