Cute Python: JPython and Python for .Net Interview
David Mertz, PH.D. President, Gnosis Software Inc. December 2000
David Mertz interviewed JPython and Python for .NET developers Mark Hammond, Finn Bock, and Barry Warsaw. He learned from Mark to some of the latest exclusive news inside information about Microsoft (of course, all content is within confidential contract restrictions), and learned from Finn and Barry to some information about JPython and the Jython projects they will publish.
Although Python is usually equivalent to CPYTHON, its specifications have achieved many times in other parts, including in applications for Java and .NET. JPython compiles the Python source code into a Java bytecode and provides transparent access to the Java class. Python for .NET is an application in Microsoft's intersessional technology platform work. During the interview with Mark Hammond, Finn Bock, and Barry Warsaw, I found more information about JPython and Python for .NET, and what preparations for future replacement Python implementations.
Python for .NET is well known in the PythonWin environment and Pythoncom extension, Mark Hammond is well known to the majority of Python programmers. For the same reason as we admire Mark, Microsoft also value him. They decided to help him in the implementation of Python for .NET. According to Mark, the work version of Python for .NET should be available soon, now you should already get its Alpha or Beta version from ActiveState (see Resources).
David Mertz: What is Python for .NET? I think I especially want to know what Python for .NET is in your own relationship between CPYTHON PythonWin and Pythoncom extensions (they seem to be able to control the internal interior of Windows).
Mark Hammond: Python for .NET is a compiler and runtime, which implements Python on Microsoft .NET platform. The .NET platform provides a runtime and metadata system, which is designed to allow complete language interoperability, but to achieve this, the language must be used in this runtime.
For example, if the Python class is a public so that the Visual Basic programmer can inherit it, the Python class must be implemented and described in .NET terminology rather than CPYTHON terms.
The advantage of Python .NET is only to interoperate with the .NET framework. There are still many defects here, mainly due to immature is not mature. But this is really just a problem. We are still in the Beta phase of development and debugging.
Mertz: What is your problem with the current Python for .NET and CPYTHON?
Hammond: Yes, most modules have not been implemented, so the modules written in C are not exactly. If your goal is not .NET framework, it is best not to use Python .NET at this time.
Mertz: However, Python for .NET must have some main advantages, such as convenient language inter-language communication and multilingual application development. But why do you say that more than already, such as Python C Swig (of course, it is a hypothesis). Hammond: It should be obvious on the current development of Python C SWIG. Language calls never don't be as difficult as Python C SWIG. But SWIG is a great product in many other aspects. It uncovered the mystery of Python C extension and only returned it to difficult rows.
Compare .NET and COM or CORBA more reasonable. Both COM and CORBA provide cross-language calls "Positive" solutions without any manual participation or compilation. .NET will take it step by step and provide cross-language inheritance and abnormal capacity. These advantages are very similar to those found in the multilingual implementation under the Java virtual machine.
Mertz: Python for .NET compiles the Python script into an external virtual machine. Whether the .NET VM will support some foreign features of Stackless and Vyper, such as continuity, generators, collaboration procedures, tails, or delay, what do you think is this?
Hammond: Yes, from theory it will. However, some of the Microsoft Beta protocols do not allow me to talk about performance issues. Let us only specify those features defined in the core Python language reference. Useless information collection is inherited, like this in JPython and JVM.
Mertz: Next to talk about policy themes, why do you think Microsoft is working on Python for .NET?
Hammond: This chooses to choose the target .NET can use Python. Microsoft has long been determined to participate in Python and many other languages to ensure that their VM is indeed unable to use language. Based on the feedback from various language implementation, now they have made a lot of changes to their VM.
Mertz: What is the financial relationship between Python for .NET? Do you pay them? Or they pay you?
Hammond: About building Python for .NET, Greg Stein and I have a contract with Microsoft. The provisions of the contract are confidential. But I am basically working for ActiveState (Perl for .NET implementation). To complete the transplant, I hope that they will eventually sign similar contracts with Microsoft.
Mertz: What does this mean about the license terms included with Python for .Net?
Hammond: It will come with "(c) Microsoft instructions, but it must be used free of charge.
Mertz: I have been worried that Microsoft will try to use special extensions and enhancements similar to "adopting, expanding, abolishing" strategy. In other words, I am afraid Python for .NET can't really be really beneficial to Python for a long time.
Hammond: If .net is a very important force, then the Python implementation of its Python helps Python, which helps Python with JPython for JVM.
JPYTHON Although JPython is a real-oriented result, Barry Warsaw and Finn Bock are currently two most active JPython developers. Unfortunately, JPython initiator Jim Hugunin no longer engaged in its development. On my website, this interview has not been deleted (more technical) versions (see Resources). David Mertz: What is JPYTHON?
Barry Warsaw: I will answer this question with standard marketing sayings.
JPYTHON is 100% pure Java implementation of Python programming languages. It allows users to compile the Python source code into a Java bytecode and run the generated bytecode on any Java virtual machine. It is the most seamless integration with Java. You can access all Java libraries from Python, build applet, integrate with Java Bean, and create subclands from the Java class in Python, and vice versa. JPYTHON is similar to Python instead of Java, it can use it to use; just see the results immediately on the prompts to enter some JPYTHON code.
In the simple words, JPython can write scripts for any Java code you need, so that the number of lines that are converted more than 2 to 10 times more than the original. Because Python is a dynamically entered language, it can develop error less applications more quickly, and get more flexible programs.
Mertz: How is the development of JPython started?
Warsaw: JPython is invented by Jim Hugunin, and he is now working for the Xerox Parc's Aspect Oriented Programming project. I understand Jim, he may be mainly interested in challenges. Many people in the Python areas think this is not achievable. Guido yourself is a skeptic. Jim proves that they are all wrong!
So since the challenge, why should I continue to develop JPYTHON? Because it is the most valuable Java tool that most Java programmers don't know. so far!
Mertz: What do you think stimulate JPython's demand?
Warsaw: First, you must understand JPython is not a competitor of Java; it is best to supplement it. Java is a static input compile language. This ensures that the input is safe and the speed is faster. There is a phenomenon is interesting, it is, although it is a zyoncode translation, but most people still think of Java as a traditional "write-compile-run-edit" program. Of course, Java uses most of the software world, so there are many resources available for Java programmers.
But the same static input and traditional programming cycles have added the cost of Java application development in human resources. Python is absolutely better in this area. Because Python is a small and simple language, it is very easy to master. Most experienced programmers can learn enough Python knowledge to improve productivity at approximately one day. Python's design idea is much more written in code. Therefore, the Python source code is easy to share in large group projects.
But more importantly, Python is a very advanced dynamic input language. This is manifested in great savings that the number of code required to perform the task is greatly saved. Because the number of lines written in Python have fewer lines, it can be written faster and less error. This is a great great for fast application development.
Python also provides an interactive interpreter that you can sit in the interpreter prompt, import Java code, create a Java class instance, and make method calls, etc. All of this is interactive. This is a great tool in how training programmers use the company's Java library or test the new Java API. But with me, all programmers should have CPYTHON and JPYTHON.
Mertz: When you look, JPYTHON is better than CPYTHON?
BOCK: JPython provides a complete access to its underlying realization language. In most (possibly all) C-based scripting languages, the C function must be packaged in a simple code used to expose the C function to the scripting language, there are some good tools, such as swig, to make this package Automation of the creation of the code code. But JPython does not need to be packaged. All Java code that have been written can be used directly from JPython, integration is two-way. Classs and instances defined by JPython can be passed to Java, just like they are general Java classes and instances (which is also true).
Embed / extended API makes access to JPython objects from the application or module. This advantage part from JPython and Java is an object-oriented language. JIM uses this important advantage.
Warsaw: CPYTHON is lacking is access to a large number of Java code in the world. If you need to use a Java library, JPython is the answer. Conversely, of course, JPython has no simple access to all existing C libraries in the world. FINN has completed the work of things such as Tkinter and POSIX modules through JNI, but those are always non-standard in JPython, because we want to retain 100% pure Java certification.
Mertz: What are the shortcomings of JPython?
FINN BOCK: JPYTHON only provides access to Java code without providing access to all existing C modules. Therefore, each Python module implemented in c must be reused with Java. CPYTHON has many modules.
In addition, there is no documentation other than source code for embedding / extended APIs.
MERTZ: Are you looking for the advantages of JPython better than pure Java?
Warsaw: I think we have already talked about many of this. But now let us talk about JPython performance issues. Because JPython implements Python's dynamic semantics, all JPython has a fairly wide runtime. This has a performance impact on some applications. For example, standard Java optimization such as instant compiler and HotSpot technology can greatly alleviate this effect (eight months ago, using JVM support JIT, JPython 1.1 can be reached, sometimes exceeding CPython 1.5.2 speed). We will update these benchmarks and focus on performance issues after launching JPython.
But like CPYTHON, you can always use the performance key part of the application in Java.
Mertz: How many extensive uses do you think JPYTHON?
Warsaw: I think it is getting more and more wide. People have gradually found it is very important for technology success. JPython has valuable tasks that create an environment from the script of the End User, to create a test framework for Java libraries and applications. At this point JPython's biggest regret is that it needs more publicity. I hope this article can help this. Mertz: Do you think JPYTHON is trying to keep up with CPYTHON attempt?
Bock: Yes. Now, JPython is trying to catch it. Almost all new features are first added to CPYTHON. (Of course, JPython has a string method before CPYTHON). JPython has deficiencies because CPYTHON is more than 15 times more core developers than JPython. But even in this, there are almost all new features in CPython 2.0 in the JPython version.
But I don't think they are almost unhappy, even in the real world, no one is better than anyone.
Warsaw: I firmly believe that JPython and CPYTHON should be fully compatible at the language level. In the case of impossible cases, GUIDO determines whether the difference is related to the implementation, or which implementation is "more wrong". I hope that CPYTHON and JPYTHON eventually become the same, JPython pushes CPython development and CPYTHON development in some ways.
An example of current it is UNICODE support. JPython is already all Unicode. Another example is type / class division. In CPYTHON, you can have some built-in types, such as strings, dictionaries, lists, and numbers. There are also classes and examples. Built-in types cannot be inherited. What is more confusing is that an example has both types and classes. First make up this shortage in JPython is more likely to be object-oriented.
Mertz: How do you think about JPython and CPYTHON?
Warsaw: There are many small differences in the method of work. They are all made in JPython documents. Some acceptable differences in providing language definitions, some means that one or other implementation should be corrected. Most of them are going very second.
BOCK: Some modules have not yet or cannot be implemented in JPython. Some modules can only be implemented as a JNI module, and similar modules are useless in the deployment environment.
BOCK: In fact, when I transplanted my script and program (together with IDLE, Pysol and PMW Toolbox), I encountered the problem that I encountered is a random reclamation or lack of _del_method. They are small problems that others have not encountered before, such as CPYTHON behavior.
Warsaw: The next version of JPython will be compatible with Python 2.0 language, so the biggest change will be in the library. The standard library module written in the CPython release should be portable. The C expansion module is not in unless they are re-implemented in Java, unless they are integrated with JNI bridge. Any JPython app that uses Java API will pass a difficult period when transplanting CPYTHON.
On the other hand, there are many public functions in the libraries of the two systems. The compatibility layer can be built into the application under the premise of deeply speaking.
MERTZ: Is there any idea for JPython in the future?
Warsaw: We have created JPython successor "Jython based on the public JPYTHON 1.1 release. This is to ensure the longness and stability of the project. All of this is implemented according to CNRI JPython 1.1.x license. We move the entire development process to SourceForge and manage it with a very suitable open process of CPYTHON. FINN and I have no doubts about Jython's future development; Jython will be issued using the CPYTHON 2.0 license approved by OSI. It is close to the "official" derived you will get, so the current JPython community should be confident that Jython will never differ much from it. We hope that they can eventually migrate to Jython. The code is still in the test phase, but FINN and I will work to establish several technical milestones for Jython 2.0 distribution (errata that already contains FINN). CPython 2.0 has enhanced assignments and expansion printing features (soon a list of lists). We have integrated free Apache Jakarta OROMATCHER code, eliminating the needs of dual licenses and fixes many errors. I don't know when Jython 2.0's first alpha distribution appears, but all current code is available in the SourceForge CVS tree.
