[Zope-CVS] CVS: PythonNet - README.txt:1.8 makefile:1.8
makefile.mono:1.4
Brian Lloyd
cvs-admin at zope.org
Wed Oct 22 22:53:40 EDT 2003
Update of /cvs-repository/PythonNet
In directory cvs.zope.org:/tmp/cvs-serv22945
Modified Files:
README.txt makefile makefile.mono
Log Message:
Lots of fixes to support Python 2.3.2, new sneaky CLR.dll stub to support
loading the managed runtime into a plain CPython process, prep for b1.
=== PythonNet/README.txt 1.7 => 1.8 ===
--- PythonNet/README.txt:1.7 Tue Sep 30 20:43:11 2003
+++ PythonNet/README.txt Wed Oct 22 22:53:08 2003
@@ -1,94 +1,37 @@
Python for .NET
Python for .NET is an integration of the C Python engine with the .NET
- Common Language Runtime. If you have questions, comments or any really
- good jokes, send them to me: brian at zope.com.
+ Common Language Runtime. If you have questions, comments or the answer
+ to life, the universe and everything, send them to me: brian at zope.com.
- The current released version of Python for .NET is preview-2.
+ The current released version of Python for .NET is 1.0 beta 1.
**What is Python For .NET?**
Python for .NET gives Python programmers near-seamless integration with
- the .NET Common Language Runtime (CLR). Using this package you can script
- CLR applications or build entire applications in Python, using CLR services
- and components written in any language that targets the CLR (Managed C++,
- C#, VB, JScript, etc.).
-
- This package does *not* implement Python as a first-class CLR language - it
- does not produce managed code (IL) from Python code. Rather, it is an integration
- of the C Python engine with the .NET runtime. This approach allows you to use
- use CLR services, continue to use existing Python C extensions, and provides
- very good execution speeds.
+ the .NET Common Language Runtime (CLR) and provides a powerful tool for
+ application scripting for .NET developers. Using this package you can
+ script CLR applications or build entire applications in Python, using
+ CLR services and components written in any language that targets the
+ CLR (Managed C++, C#, VB, JScript, etc.).
+
+ This package does *not* implement Python as a first-class CLR language -
+ it does not produce managed code (IL) from Python code. Rather, it is
+ an integration of the C Python engine with the .NET runtime. This
+ approach allows you to use use CLR services and continue to use existing
+ Python C extensions while maintaining native execution speeds for Python
+ code.
-
- **What is the license?**
-
- This package is released under the open source Zope Public License (ZPL).
- A copy of the ZPL is included in the distribution, or you can find the
- ZPL online at: http://www.zope.org/Products/Zope/LICENSE_20.txt.
-
- Ready-to-run distributions of this package include a copy of the CPython
- dlls and standard library, which are covered by the Python license.
-
-
- **Does it work with Mono?**
-
- Preliminary testing shows that PythonNet can run under mono,though the test
- suite bombs out before the end with an "out of memory" error from the mono runtime.
- It's just a guess at this point, but I suspect there may be a limited pool for
- allocating certain reflection structures, and Python uses the reflection infrastructure
- quite heavily.
-
- It is not currently possible to *build* PythonNet using only the Mono tools, due to
- an issue involving the Mono assembler / disassembler. You should, however, be able
- to run the pre-built assembly under Mono (or compile it yourself with the MS tools
- and run it under Mono).
-
- Note that if you are running under Mono on a *nix system, you will need to have
- Python 2.2.3 installed. You will probably also have to make a symlink in the
- PythonNet directory pointing to the libpython2.2.so on your system. You will
- need to name the symlink 'python22.so'.
-
-
- **What is the current status of the package?**
-
- I still consider it experimental, in that I've focused on working out
- the core architecture to support a natural experience for the Python
- programmer. Little or no effort has yet gone in to packaging and
- deployment issues, embedding APIs and other things that would be
- required for a production-quality release.
-
- At this point, most of the core concepts of the integration are working,
- it is possible to build real applications, and there are a respectable
- number of unit tests.
-
- Some caveats of the current release:
-
- - The package is currently a self-contained private assembly, which
- includes a copy of Python 2.2. The python.exe is actually a managed
- wrapper to bootstrap the CLR support. In the future we may want to
- provide a bootstrap module that is a normal Python C extension so
- that you can use an external CPython. Since that starts to get into
- packaging issues, I've punted on that for now.
-
- - There is still a bad interaction with the Python GC, so the managed
- python.exe currently forcibly disables Python GC until I can track
- that down.
-
- - Resolution of overloaded methods is pretty brain-dead right now. It
- needs to be fixed to weight argument types.
-
- My hope is to find a group of people interested enough in .NET support
- to help finish working out the details for remaining issues like
- deployment, embedding, etc.
+ Python for .NET is based on Python 2.3.2. Note that this is a change from
+ the preview releases, which were based on Python 2.2.
Is This Like Jython for .NET?
- No. Jython provides an implementation of the Python language and runtime
- in pure Java. Python for .NET is not a re-implementation of Python, just an
- integration of the existing CPython runtime with .NET.
+ Not really. Jython provides an implementation of the Python language and
+ runtime engine in pure Java. Python for .NET is not a re-implementation
+ of Python, just an integration of the existing CPython runtime with .NET.
While a solution like Jython provides "two-way" interoperability, this
package only provides "one-way" integration. Meaning, while Python can
@@ -106,6 +49,68 @@
paper describing the goals and results at http://www.activestate.com.
+ **What is the license?**
+
+ This package is released under the open source Zope Public License (ZPL).
+ A copy of the ZPL is included in the distribution, or you can find the
+ ZPL online at: http://www.zope.org/Products/Zope/LICENSE_20.txt.
+
+ Ready-to-run distributions of this package include a copy of the CPython
+ dlls and standard library, which are covered by the Python license.
+
+
+ **Does it work with Mono?**
+
+ Preliminary testing shows that PythonNet will run under mono, though the
+ test suite fails quickly due to NotImplemented errors raised in parts of
+ the Mono runtime. The PythonNet integration layer is 100% managed code,
+ so there are no long-term issues under mono - it should work better and
+ better as the mono platform matures.
+
+ It is not currently possible to *build* PythonNet using only the Mono
+ tools, due to an issue involving the Mono assembler / disassembler. You
+ should, however, be able to try the pre-built assembly under Mono (or
+ compile it yourself with the MS tools and run it under Mono).
+
+ Note that if you are running under Mono on a *nix system, you will need
+ to have Python 2.3 installed. You will probably also have to make a
+ symlink in the PythonNet directory pointing to the libpython2.3.so on
+ your system. You will need to name the symlink 'python23.so'.
+
+
+ **What is the current status of the package?**
+
+ As of beta 1, the Python for .NET runtime is quite stable and is nearly
+ feature-complete. There are a large number of unit tests as well as a
+ number of stress tests, leak tests and demo scripts. There are still
+ some loose ends to finish up for the 1.0 release (see below), but it
+ is definitely usable for real applications.
+
+
+ Known issues with the current release:
+
+ - Python classes can't yet implement interfaces or abstract classes. I
+ do have a proof of concept working, so I'm hopeful that will make it
+ in for 1.0.
+
+ - Behavior in complex multithreaded applications is not well tested - it
+ is possible that there are still deadlock situations lurking. I plan
+ to write some high-stress threading tests before 1.0, but feedback
+ from people with real applications would be very helpful.
+
+ - Managed exceptions are not integrated well with Python exceptions, due
+ to Python's insistence that exceptions must be old-style classes. Not
+ sure if there is a sneaky way around it, other than lobbying Guido to
+ look at it for Python 2.4.
+
+ - Resolution of overloaded methods could be better and will be by
+ 1.0, but in the meantime it is pretty brain-dead for methods with
+ a lot of overloads.
+
+ - Packaging is still pretty minimal. There should probably be an msi
+ installer etc. for win32.
+
+
**How do I install the package?**
A current snapshot of the package is available at:
@@ -120,32 +125,46 @@
at http://dev.zope.org/CVS/ReadOnlyAccess to check out the 'PythonNet'
package. After checking it out, cd to the directory and run 'make' to
build it (you must have the .NET dev kit installed to do this). You
- must also have a copy of Python 2.2 installed on your machine.
+ must also have a copy of Python 2.3 installed on your machine.
Note that if you are running using Mono on Linux you will probably need
to create a symbolic link to the copy of libpython22.so (in your existing
Python installation) in the PythonNet directory, for example:
- ln -s /usr/lib/libpython2.2.so ./libpython22.so
+ ln -s /usr/lib/libpython2.3.so ./libpython22.so
+
+
+ **Can I use it with my existing Python installation?**
+
+ Yes, at least on win32 systems. Just copy the files Python.Runtime.dll
+ and CLR.dll from the PythonNet directory to the root directory of your
+ python installation.
**How do I use it?**
Until there is "real" documentation, I'll try to keep this reasonably
- up to date to give quick usage examples. A key idea for this project
+ up to date to give quick usage examples. A key goal for this project
has been that it should "work just the way you'd expect in Python",
except for cases that are .NET specific (in which case the goal is to
work "just the way you'd expect in C#").
+ I think that those goals have been met pretty well. If you already know
+ Python, you can probably finish this readme and then refer to .NET docs
+ to figure out anything you need to do. Conversely if you are familiar
+ with C# or another .NET language, you probably just need to pick up one
+ of the many good Python books or look online at http://www.python.org
+ to get started.
+
If you want to find out about any kind of usage not shown here, the
- unit tests are probably a good place to look for examples.
+ unit tests and demo scripts are a good place to look for examples.
**Importing .NET namespaces**
An import hook allows CLR namespaces to be treated essentially as
Python packages. The "top-level" package is named 'CLR', and acts as
- the root for accessing CLR namespaces::
+ the root for accessing all CLR namespaces::
from CLR.System import String
import CLR.System as System
@@ -153,7 +172,7 @@
Types from any loaded assembly may be imported and used in this manner.
The import hook uses "implicit loading" to support automatic loading
- of assemblies whose names correspond to a namespace::
+ of assemblies whose names correspond to an imported namespace::
# This will implicitly load the System.Windows.Forms assembly
@@ -174,14 +193,19 @@
Note that CLR modules are "lazy". Because a namespace can contain a
potentially very large number of classes, reflected CLR classes are
- created on-demand when they are requested of a CLR module.
+ created on-demand when they are requested of a CLR module. This means
+ that using the Python 'dir()' function in the interactive interpreter
+ will not necessarily show all of the classes available from a given
+ CLR module (it will only show any classes that have been referenced to
+ that point in time).
**Using .NET Classes**
- You can import and use any non-private class from any loaded assembly
- in Python. To create an instance, pass the class arguments that match
- one of its public constructors::
+ Python for .NET allows you to use any non-private classes, structs,
+ interfaces, enums or delegates from Python. To create an instance of
+ a managed class, you use the standard instantiation syntax, passing
+ a set of arguments that match one of its public constructors::
from CLR.System.Drawing import Point
@@ -207,7 +231,7 @@
**Using Indexers**
If a managed object implements one or more indexers, you can call
- the indexer using standard Python indexing::
+ the indexer using standard Python indexing syntax::
from CLR.System.Collections import Hashtable
@@ -265,7 +289,7 @@
Events are treated as first-class objects in Python, and behave in
many ways like methods. Python callbacks can be registered with event
- attributes, and events can be called to fire the event.
+ attributes, and an event can be called to fire the event.
Note that events support a convenience spelling similar to that used
in C#. You do not need to pass an explicitly instantiated delegate
@@ -316,7 +340,7 @@
**Using Collections**
Managed arrays and managed objects that implement the IEnumerable interface
- can be iterated using the standard Python idiom::
+ can be iterated using the standard iteration Python idioms::
domain = System.AppDomain.CurrentDomain
@@ -326,7 +350,7 @@
**Using COM Components**
- You can use the (MS-provided) aximp and tlbimp tools to generate
+ You can use the (MS-provided) aximp.exe and tlbimp.exe tools to generate
managed wrappers for COM libraries. After generating the wrapper,
you can use the libraries from Python just like any other managed
code.
@@ -345,7 +369,7 @@
a logical equivalent in Python are instances of managed types.
Note that all strings returned from CLR methods, properties, etc.
- are returned as unicode, for the sake of my sanity :)
+ are returned as unicode.
**Security**
@@ -362,25 +386,21 @@
**Does it support embedding?**
- The Python runtime assembly will eventually expose APIs to allow easy
- embedding in managed applications. Some bits of those APIs exist in a
- broken and scratch-pad way right now, but are definitely not ready
- for prime-time. I expect fairly major refactoring to continue for a
- while, so use of any exported APIs from other managed code should be
- considered "at your own risk" :^)
+ The Python runtime assembly defines a number of public classes that
+ provide a subset of the functionality provided by the Python C API.
+
+ These classes include PyObject, PyList, PyDict, etc. The source and
+ the unit tests are currently the only documentation (though I've tried
+ to document it clearly in the source). The rhythym is very similar to
+ using Python C++ wrapper solutions such as CXX.
**Does it work with Zope?**
- Yes, but PythonNet is based on Python 2.2, so you'll need to build a
- Zope from source against Python 2.2. After that, change the z2.py
+ Yes, but PythonNet is based on Python 2.3, so you'll need to build a
+ Zope from source against Python 2.3. After that, change the z2.py
(or rather the start.bat file on windows) to point to the python.exe
in the managed assembly.
-
- Note that the CLR is free-threaded, and I haven't worked out all of
- the thread choreography yet, so you should avoid managed code with
- threading concerns (especially COM wrappers) until things are a
- little more mature.
**How can I report bugs?**
=== PythonNet/makefile 1.7 => 1.8 ===
--- PythonNet/makefile:1.7 Mon Oct 20 23:05:11 2003
+++ PythonNet/makefile Wed Oct 22 22:53:08 2003
@@ -7,7 +7,7 @@
ILASM=ilasm
CSC=csc.exe
-all: python.exe Python.Test.dll
+all: python.exe CLR.dll Python.Test.dll
python.exe: Python.Runtime.dll
@@ -32,6 +32,12 @@
rm -f Python.Runtime.res;
rm -f ./CallConvUtil.exe;
+
+CLR.dll: Python.Runtime.dll
+ $(ILASM) /nologo /dll /quiet /output=CLR.dll \
+ ./src/runtime/CLRModule.il;
+
+
Python.Test.dll: Python.Runtime.dll
cd src; cd testing; \
$(CSC) /nologo /target:library /out:../../Python.Test.dll \
@@ -51,6 +57,7 @@
clean:
rm -f python.exe Python*.dll Python*.il Python*.il2 Python*.res
rm -f CallConvUtil.exe
+ rm -f CLR.dll
rm -f ./*~
cd src; cd console; rm -f *~; cd ..; cd ..;
cd src; cd runtime; rm -f *~; cd ..; cd ..;
@@ -77,7 +84,7 @@
make
cp ./python.exe ./$(DIRNAME)-dist/
cp ./*.dll ./$(DIRNAME)-dist/
- cp ./redist/python22.dll ./$(DIRNAME)-dist/
+ cp ./redist/python23.dll ./$(DIRNAME)-dist/
cp -R ./redist/DLLs ./$(DIRNAME)-dist/
cp -R ./redist/lib ./$(DIRNAME)-dist/
tar czf $(DIRNAME)-dist.tgz ./$(DIRNAME)-dist/
=== PythonNet/makefile.mono 1.3 => 1.4 ===
--- PythonNet/makefile.mono:1.3 Fri Aug 8 23:29:46 2003
+++ PythonNet/makefile.mono Wed Oct 22 22:53:08 2003
@@ -11,7 +11,7 @@
ILASM=ilasm
CSC=mcs
-all: python.exe Python.Test.dll
+all: python.exe CLR.dll Python.Test.dll
python.exe: Python.Runtime.dll
@@ -36,6 +36,12 @@
rm -f Python.Runtime.res;
rm -f ./CallConvUtil.exe;
+
+CLR.dll: Python.Runtime.dll
+ $(ILASM) /nologo /dll /quiet /output=CLR.dll \
+ ./src/runtime/CLRModule.il;
+
+
Python.Test.dll:
cd src; cd testing; \
$(CSC) /nologo /target:library /out:../../Python.Test.dll \
@@ -54,6 +60,7 @@
clean:
rm -f python.exe Python.Test.dll Python*.il Python*.il2 Python*.res
rm -f CallConvUtil.exe
+ rm -f CLR.dll
rm -f ./*~
cd src; cd console; rm -f *~; cd ..; cd ..;
cd src; cd runtime; rm -f *~; cd ..; cd ..;
More information about the Zope-CVS
mailing list