Need for supporting IronPython, Jython?

[rmiles]

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 first gut reaction to this is "Yes!", but after thinking about things a bit more I'm not so sure. Takes these following three scenarios (the first 2 are dead straight and simple, the third is more interesting):

1) I'm a Java developer and I need to create a Spring application. Now, am I really going to pick up Spring Python... probably not. My tool of choice is Java so I'll leap for Spring Java. If I need to add in python 'beans', then I can do that using the lang namespace that's supported in the Spring Framework for Java.

2) I'm a .NET developer and I need to create a Spring application. Now, am I really going to pick up Spring Python... probably not. My tool of choice is C#, or maybe VB, so I'll leap for Spring .NET. IF I want to feploy python 'objects' then I can either do that manually over IronPython, or I can wait for the lang namespace support...

In either of these cases, the onus is on the developer to think about the platform and tools they want to use for their job, including choice of language, and to go ahead and apply thew Spring approach in that environment. If the developer wants to use a python component, then it's their responsibility to understand that it is running on Jython or IronPython respectively. Although it's made simple in Spring to do that, using the lang namespace, the details are not hidden to the point where anything nasty, like a piece of C code barfing, is likely to happen.

Now consider a third case:

3) I'm a Python, notable a CPython, developer and I need to create a Spring application. Now, am I really going to pick up Spring Python... probably! My tool of choice is Python so I'll leap for Spring Python, makes sense. If I need to run my application on a different platform, like Java and the JVM... would I attempt to take across my existing application as it stands, or would it be more likely that I reconstruct the pertinent pieces in Spring Java (a relatively trivial task) so that I could reuse my own components (as hosted using Jython) and take advantage of all the strong integration with the Java platform inherent in the Spring framework for Java? (for the .NET equivalent, just substitute Java for .NET in the prior sentence).

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.

So, any thoughts?

[gregturn]

I think CPython takes top priority over anything. I agree with Russ' assertion that its the concepts we are porting, not the code itself. I think people are more likely the port a component onto another platform as Russ describes, and want options to integrate than they are to write-once-for-one-vm, and re-run on any other VM.

1) Jython has only recently come out with support for python 2.5 (previously was 2.2), which is a minimal requirement for SP (2.2 is too old). If the whole test suite runs in both CPython and Jython 2.5 with no edits, I would be happy and claim something. Anything else, and I say ignore Jython for now. To top it off, I can't even run pydev/eclipse with this new release of jython, so I haven't taken it seriously yet.

2) I would apply this same set of criteria to IronPython. What version of python are they at yet? If I can run the test suite with no edits successfully, lets claim it. Otherwise, move along and stick with the "real" python.

3) This will really be critical when python 3000 comes out. We will need to be supporting major stuff there, and I seriously doubt IronPython and Jython keeping up with that, so why get stuck with that?

4) I think integration with differing technologies (JVM/CLR) is more suitable through protocol like Pyro/Hessian/CORBA/REST/web services/messaging rather than byte code compatibility, and that is more what main stream developers would be wanting. It would seem that IronPython and Jython are still emerging, and frankly, haven't proven themselves yet. I mean, CPython itself is available for Linux/Solaris/Mac/Windows, so the fact that our code works for any CPython sounds good enough for our purposes.

At least, that is my opinion.

[rmiles]

I think integration with differing technologies (JVM/CLR) is more suitable through protocol like Pyro/Hessian/CORBA/REST/web services/messaging rather than byte code compatibility

This makes sense to me too, it's certainly the level of interoperability that I'm most used to looking for in a solution.

[Lawouach]

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.

I've emphasized what I believe to be the right spirit to keep while working on such project.

From my own perspective trying to implement a 1-to-1 port of project from a platform to another is never the most optimal approach. There are several reasons to that:

1. Programming languages and their environments are usually too far away from one to the other to allow such tight relationship. Even when the language itself is the same (Python is implemented with CPython, IronPython and Jython but stays Python), you cannot guarantee a proper portability of tools, products, etc.

2. Programmers, notably those who do their work in large frameworks like .NET or J2EE, are often following design principles and rules applied to the framework (even when it doesn't make the most sense to their own use case) they're using. However if your framework is too alien to habits the programmer may have he/she'll never be productive with it. An unhappy developer is not an efficient developer.

I can't speak for the Jython community but from what I've seen so far the IP community is more about .NET developers wishing to work with a dynamic language not involving the terms Visual and Basic while keeping their platform habits. In other words, IronPython projects I've seen can often look alien to CPython developers. They'll see Python and yet won't feel it is Python. Similarly I wonder if .NET developers using IronPython would be at ease with a framework that doesn't abide by the rules of their platform.

For instance Python has its own syntax guidelines [1] and we could draw examples from those that would probably displease the .NET developers. Say the fact methods are lower case and that camel case is actually tolerated only for class names. This might sound stupid but I believe it is important to make your developer at ease with your API if you want them to be efficient with it.

You can't please everyone but you can ensure you won't displease everyone if you make a clear choice in regards to your priorities. Would .NET developers that wish to code in Python prefer Spring Python over Spring.NET? Same question for Java developers. Probably not as you suggested Russ.

Consequently I believe you should not consider SP for anything else than Python. If a Python developer wants or has to use IronPython it'll be happy to know that SP probably works well under said platform and will put up with the mix between .NET and Python syntax. But SP shouldn't try to second guess those cases.

[1] http://www.python.org/dev/peps/pep-0008/

[gregturn]

Sylvain's comment raises a side question to me.

I have read the style guidelines of Python, and you may have noticed that my method names seem more java-like than python-like. I was wondering if we should be following the style guide more.

Personally, I sort of like java's lazy camel (mixedCase) style for naming methods preferable to python's lowercase/underscores, because I didn't like having an extra character. However, I don't know how this makes the code look to the python community. I don't want to alienate the python community and look like some crazy java guy trying to push people around.

How about this for a quick style survey of Spring Python's code base (compared to PEP-0008):
1. Module names are lowercased properly.

2. Class names (and exceptions) properly use camel case properly.

3. Some classes (pycontainer is the biggest example) do NOT have leading underscores, though they should, to indicate they are private.

4. Function names are using mixedCase (lazy camelcase), not lowercase with underscores. Don't know how averse that is to the python community.

5. I properly use "self" everywhere, and don't really have any class-level functions that need "cls".

The function names (and parameter names) are the biggest place I can see SP maybe looking java-ish. Don't worry about getters and setters; I didn't bring those with me! I am willing to go clean things up, and considering we have good test coverage, I'm confident it can be done with minimal risk.

And if it should be done, then we need to do it NOW, while we still have a few releases to bang against it before 1.0.

[gregturn]

Here is an example I just spotted:

def supports(self, clazzOrConfigAttribute):
    """This voter will support a list, or a string starting with
    the same characters as the set prefix.
    """
    if type(clazzOrConfigAttribute) == list:
        return True
    elif clazzOrConfigAttribute and clazzOrConfigAttribute[:len(self.rolePrefix)] == self.rolePrefix:
        return True
    else:
        return False

This should probably be:

def supports(self, clazz_or_config_attr):
    """This voter will support a list, or a string starting with
    the same characters as the set prefix.
    """
    if type(clazz_or_config_attr) == list:
        return True
    elif clazz_or_config_attr is not None and clazz_or_config_attr.startswith(self.rolePrefix):
        return True
    else:
        return False

Which of these is cleaner?

def __init__(self, labelMap = None, allowAccessIfNoAttributesAreLabeled = False, attributeIndicatingLabeledOperation = ""):
    if not labelMap:
        self.labelMap = {}
    else:
        self.labelMap = labelMap
    self.allowAccessIfNoAttributesAreLabeled = allowAccessIfNoAttributesAreLabeled
    self.attributeIndicatingLabeledOperation = attributeIndicatingLabeledOperation
    self.logger = logging.getLogger("springpython.security.vote.LabelBasedAclVoter")

...or this?

def __init__(self, label_dict = None, allow_access_if_no_attr_labeled = False, attr_indicating_labeled_op = ""):
    if not label_dict:
        self.label_dict = {}
    else:
        self.label_dict = label_dict
    self.allow_access_if_no_attr_labeled = allow_access_if_no_attr_labeled
    self.attr_indicating_labeled_op = attr_indicating_labeled_op
    self.logger = logging.getLogger("springpython.security.vote.LabelBasedAclVoter")

[Lawouach]

Number 4. is probably the most unpythonic aspect (I should be careful with that term as it is a source of conflict .

I actually like the layout you chose otherwise.

[Lawouach]

Here is an example I just spotted:

def supports(self, clazzOrConfigAttribute):
    """This voter will support a list, or a string starting with
    the same characters as the set prefix.
    """
    if type(clazzOrConfigAttribute) == list:
        return True
    elif clazzOrConfigAttribute and clazzOrConfigAttribute[:len(self.rolePrefix)] == self.rolePrefix:
        return True
    else:
        return False

This should probably be:

def supports(self, clazz_or_config_attr):
    """This voter will support a list, or a string starting with
    the same characters as the set prefix.
    """
    if type(clazz_or_config_attr) == list:
        return True
    elif clazz_or_config_attr is not None and clazz_or_config_attr.startswith(self.rolePrefix):
        return True
    else:
        return False

My take would be:

def supports(self, attr):
    """This voter will support a list, or a string starting with
    the same characters as the set prefix.
    """
    if isinstance(attr, list) or (attr is not None and attr.startswith(self.rolePrefix)):
        return True

    return False

But it's probably a personal taste here

[gregturn]

I think Sylvain has convinced me (or perhaps I convinced myself and Sylvain merely encouraged me) to go scrub this naming convention a bit. I will open a jira issue, and work one module at a time to make things a little more tasteful, python wise.

Yes, I believe if you back up your position using PEP-0008, you are working from the best documented source of "pythonic" available.

Thanks for your view of things Sylvain. That's what I need.

[gregturn]

My take would be:

def supports(self, attr):
    """This voter will support a list, or a string starting with
    the same characters as the set prefix.
    """
    if isinstance(attr, list) or (attr is not None and attr.startswith(self.rolePrefix)):
        return True

    return False

But it's probably a personal taste here

Yeah, that is even better!