[Zope-CVS] CVS: PythonNet - makefile.mono:1.1 README.txt:1.3 makefile:1.5
Brian Lloyd
brian@zope.com
Thu, 24 Jul 2003 19:55:26 -0400
Update of /cvs-repository/PythonNet
In directory cvs.zope.org:/tmp/cvs-serv24649
Modified Files:
README.txt makefile
Added Files:
makefile.mono
Log Message:
commit refactorings
=== Added File PythonNet/makefile.mono ===
# Makefile for the PythonRuntime .NET assembly and tests. Thanks to
# Camilo Uribe <kmilo@softhome.net> for contributing Mono support.
DIRNAME=PythonNet
RUNNER=mono
ILDASM=monodis
ILASM=ilasm
CSC=mcs
all: python.exe Python.Test.dll
python.exe: Python.Runtime.dll
cd src; cd console; \
$(CSC) /nologo /target:exe /out:../../python.exe \
/reference:../../Python.Runtime.dll /recurse:*.cs
cd ..; cd ..;
Python.Runtime.dll: CallConvUtil.exe
cd src; cd runtime; \
$(CSC) /nologo /unsafe /target:library /out:../../Python.Runtime.dll \
/recurse:*.cs
cd ..; cd ..;
$(ILDASM) Python.Runtime.dll --output=Python.Runtime.il;
$(RUNNER) ./CallConvUtil.exe;
$(ILASM) /nologo /quiet /key=Python.Runtime.key /dll \
/resource=Python.Runtime.res /output=Python.Runtime.dll \
Python.Runtime.il2;
rm -f Python.Runtime.il;
rm -f Python.Runtime.il2;
rm -f Python.Runtime.res;
rm -f ./CallConvUtil.exe;
Python.Test.dll: Python.Runtime.dll
cd src; cd testing; \
$(CSC) /nologo /target:library /out:../../Python.Test.dll \
/reference:../../Python.Runtime.dll \
/recurse:*.cs
cd ..; cd ..;
CallConvUtil.exe:
cd src; cd tools; \
$(CSC) /nologo /target:exe /out:../../CallConvUtil.exe \
/recurse:*.cs
cd ..; cd ..;
clean:
rm -f python.exe Python*.dll Python*.il Python*.il2 Python*.res
rm -f CallConvUtil.exe
rm -f ./*~
cd src; cd console; rm -f *~; cd ..; cd ..;
cd src; cd runtime; rm -f *~; cd ..; cd ..;
cd src; cd testing; rm -f *~; cd ..; cd ..;
cd src; cd tools; rm -f *~; cd ..; cd ..;
cd tests; cd python; rm -f *.pyc; rm -f *~; cd ..; cd ..;
test:
rm -f ./tests/python/*.pyc
$(RUNNER) ./python.exe ./tests/python/runtests.py
dist: clean
mkdir ./$(DIRNAME)-dist
cp -R ./makefile ./$(DIRNAME)-dist/
cp -R ./*.txt ./$(DIRNAME)-dist/
cp -R ./demo ./$(DIRNAME)-dist/
cp -R ./doc ./$(DIRNAME)-dist/
cp -R ./nunit ./$(DIRNAME)-dist/
cp -R ./src ./$(DIRNAME)-dist/
cp -R ./tests ./$(DIRNAME)-dist/
make
cp ./python.exe ./$(DIRNAME)-dist/
cp ./*.dll ./$(DIRNAME)-dist/
cp ./redist/python22.dll ./$(DIRNAME)-dist/
cp -R ./redist/DLLs ./$(DIRNAME)-dist/
cp -R ./redist/lib ./$(DIRNAME)-dist/
tar czf $(DIRNAME)-dist.tgz ./$(DIRNAME)-dist/
rm -rf ./$(DIRNAME)-dist/
dis:
$(ILDASM) Python.Runtime.dll /out=Python.Runtime.il
asm:
$(ILASM) /dll /quiet \
/resource=Python.Runtime.res /output=Python.Runtime.dll \
Python.Runtime.il
=== PythonNet/README.txt 1.2 => 1.3 ===
--- PythonNet/README.txt:1.2 Mon Jul 14 14:34:00 2003
+++ PythonNet/README.txt Thu Jul 24 19:54:51 2003
@@ -1,9 +1,331 @@
Python Scripting For .NET
This is an experimental integration of CPython with the .NET Common
- Language Runtime. See the FAQ.txt in the /doc directory for more
- details on usage.
+ Language Runtime. If you have questions, comments or huge bags 'o cash,
+ send them to brian@zope.com :)
- brian@zope.com
+ **What is Python Scripting For .NET?**
+ Python Scripting For .NET provides Python programmers with 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* make Python a first-class CLR language - it does
+ not produce managed code from Python code. Rather, it is an integration
+ of the C Python engine with the .NET runtime. This approach allows you to
+ use CLR services, continue to use existing Python C extensions, and
+ provides decent speed.
+
+
+ **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?**
+
+ Mostly :) Some things to note about running under Mono:
+
+ One, it is not currently possible to *build* PS.NET using only the
+ Mono tools, due to an issue involving the Mono assembler / disassembler.
+ Mono can, however, run the assembly as-is after being built with the
+ MS tools.
+
+ Two, if you are running on a *nix system, you will likely need to
+ create a symbolic link to the libpython22.so on your system in the
+ PS.NET directory so that Mono can find and load the Python shared
+ library.
+
+ Third, Mono is under heavy development - while most of the PS.NET
+ unit tests run, it looks like there are still some parts of the
+ runtime that have yet to be implemented or still have issues that
+ might prevent you from doing certain things in Python.
+
+
+ **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 will 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'll 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.
+
+
+ Is This Like Jython for .NET?
+
+ No. Jython provides an implementation of the Python language and runtime
+ in pure Java. Python Scripting 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
+ use types and services implemented in .NET, managed code cannot generally
+ use classes implemented in Python.
+
+ A Jython-like solution for .NET would certainly be doable and useful - but
+ it would also be a lot more work than the current approach.
+
+
+ Is This Related To ActiveState's Python.NET Work?
+
+ No. That effort focused on the feasibility of making Python a true .NET
+ language (compiling Python to IL). You can find that work as well as a
+ paper describing the goals and results at http://www.activestate.com.
+
+
+ **How do I install the package?**
+
+ A current snapshot of the package is available at:
+
+ http://www.zope.org/Members/Brian/PythonNet/
+
+ The release snapshot is a self-contained "private" assembly. Just unzip
+ the package wherever you want it, cd to that directory and run
+ python.exe to start using it.
+
+ You can also run it from CVS. Use the "read-only access" CVS instructions
+ 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.
+
+ 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 PS.NET directory, for example:
+
+ ln -s /usr/lib/libpython2.2.so ./libpython22.so
+
+
+ **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
+ 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#").
+
+ 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.
+
+
+ **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::
+
+ from CLR.System import String
+ import CLR.System as System
+
+
+ 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::
+
+ # This will implicitly load the System.Windows.Forms assembly
+
+ from CLR.System.Windows.Forms import Form
+
+
+ To load assemblies with names that do not correspond with a namespace,
+ you can use the standard mechanisms provided by the CLR::
+
+ from CLR.System.Reflection import Assembly
+
+ a = Assembly.LoadWithPartialName("SomeAssembly")
+
+ # now we can import namespaces defined in that assembly
+
+ from CLR.SomeNamespace import Something
+
+
+ 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.
+
+
+ **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::
+
+ from CLR.System.Drawing import Point
+
+ p = Point(5, 5)
+
+
+ **Fields And Properties**
+
+ You can get and set fields and properties of CLR objects just as if
+ they were regular attributes::
+
+ from CLR.System import Environment
+
+ name = Environment.MachineName
+ Environment.ExitCode = 1
+
+
+ **Using Methods**
+
+ Methods of CLR objects behave generally like normal Python methods.
+ Static methods may be called either through the class or through an
+ instance of the class. All public and protected methods of CLR objects
+ are accessible to Python::
+
+ from CLR.System import Enviroment
+
+ drives = Environment.GetLogicalDrives()
+
+
+ **Delegates And Events**
+
+ Delegates defined in managed code can be implemented in Python. A
+ delegate type can be instantiated and passed a callable Python object
+ to get a delegate instance. The resulting delegate instance is a true
+ managed delegate that will invoke the given Python callable when it
+ is called.::
+
+ def my_handler(source, args):
+ ...
+
+ # instantiate a delegate
+
+ d = AssemblyLoadEventHandler(my_handler)
+
+ # use it as an event handler
+
+ AppDomain.CurrentDomain.AssemblyLoad += d
+
+
+ Multicast delegates can be implemented by adding more callable objects
+ to a delegate instance::
+
+ d += self.method1
+ d += self.method2
+ d()
+
+
+ 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.
+
+ Note that events support a convenience spelling similar to that used
+ in C#. You do not need to pass an explicitly instantiated delegate
+ instance to an event (though you can if you want). Events support the
+ '+=' and '-=' operators in a way very similar to the C# idiom::
+
+ def handler(source, args):
+ ...
+
+ # register event handler
+
+ object.SomeEvent += handler
+
+ # unregister event handler
+
+ object.SomeEvent -= handler
+
+ # fire the event
+
+ result = object.SomeEvent(...)
+
+
+ **Deriving From .NET Classes**
+
+ This is nearly, but not quite working. It's actually only working
+ enough to start working on unit tests :) The architecture is designed
+ to allow for single-inheritance from managed types.
+
+
+ **Using COM Components**
+
+ You can use the (MS-provided) aximp and tlbimp 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.
+
+ Note: currently you need to put the generated wrappers in the GAC
+ or in the PS.NET assembly directory in order to load it. Future
+ versions will likely come up with some way of extending the load
+ path (something like a sys.path for managed assemblies).
+
+
+ **Type Conversion**
+
+ Need to document type conversion here. The short answer is: most
+ simple Python types (string, int, long, etc.) convert automatically
+ to managed equivalents (String, Int32, etc.). Types that do not have
+ a logical equivalent in Python are instances of managed types.
+
+ Note that all strings returned from CLR methods, properties, etc.
+ are returned as unicode.
+
+
+ **Security**
+
+ Because Python code is inherently unverifiable, Python code runs
+ totally under the radar of the security infrastructure of the CLR.
+ It hasn't been decided yet exactly what permissions the PS.NET
+ assembly will demand to run, but it will
+
+
+ **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" :^)
+
+
+ **Does it work with Zope?**
+
+ Yes, but PS.NET 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
+ (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?**
+
+ I haven't yet set up a mailing list for the project - if there is
+ enough interest I will do so. Until then, please email me with any
+ issues: brian@zope.com.
=== PythonNet/makefile 1.4 => 1.5 ===
--- PythonNet/makefile:1.4 Mon Jul 14 16:09:31 2003
+++ PythonNet/makefile Thu Jul 24 19:54:51 2003
@@ -1,60 +1,95 @@
-# Makefile for the PythonRuntime .NET assembly and tests.
+# Makefile for the PythonRuntime .NET assembly and tests. Thanks to
+# Camilo Uribe <kmilo@softhome.net> for contributing Mono support.
+DIRNAME=PythonNet
+RUNNER=
+ILDASM=ildasm
+ILASM=ilasm
CSC=csc.exe
all: python.exe Python.Test.dll
python.exe: Python.Runtime.dll
- cd src; cd console; make; cd ..; cd ..;
+ cd src; cd console; \
+ $(CSC) /nologo /target:exe /out:../../python.exe \
+ /reference:../../Python.Runtime.dll /recurse:*.cs
+ cd ..; cd ..;
Python.Runtime.dll: CallConvUtil.exe
- cd src; cd runtime; make; cd ..; cd ..;
- ildasm /nobar Python.Runtime.dll /out=Python.Runtime.il;
- ./CallConvUtil.exe;
- ilasm /nologo /quiet /key=Python.Runtime.key /dll \
+ cd src; cd runtime; \
+ $(CSC) /nologo /unsafe /target:library /out:../../Python.Runtime.dll \
+ /recurse:*.cs
+ cd ..; cd ..;
+ $(ILDASM) /nobar Python.Runtime.dll /out=Python.Runtime.il;
+ $(RUNNER) ./CallConvUtil.exe;
+ $(ILASM) /nologo /quiet /key=Python.Runtime.key /dll \
/resource=Python.Runtime.res /output=Python.Runtime.dll \
Python.Runtime.il2;
rm -f Python.Runtime.il;
rm -f Python.Runtime.il2;
rm -f Python.Runtime.res;
-
+ rm -f ./CallConvUtil.exe;
Python.Test.dll: Python.Runtime.dll
- cd src; cd testing; make; cd ..; cd ..;
+ cd src; cd testing; \
+ $(CSC) /nologo /target:library /out:../../Python.Test.dll \
+ /reference:../../Python.Runtime.dll \
+ /recurse:*.cs
+ cd ..; cd ..;
CallConvUtil.exe:
- cd src; cd tools; make; cd ..; cd ..;
+ cd src; cd tools; \
+ $(CSC) /nologo /target:exe /out:../../CallConvUtil.exe \
+ /recurse:*.cs
+ cd ..; cd ..;
clean:
- cd src; cd console; make clean; cd ..; cd ..;
- cd src; cd runtime; make clean; cd ..; cd ..;
- cd src; cd testing; make clean; cd ..; cd ..;
- cd src; cd tools; make clean; cd ..; cd ..;
+ rm -f python.exe Python*.dll Python*.il Python*.il2 Python*.res
+ rm -f CallConvUtil.exe
+ rm -f ./*~
+ cd src; cd console; rm -f *~; cd ..; cd ..;
+ cd src; cd runtime; rm -f *~; cd ..; cd ..;
+ cd src; cd testing; rm -f *~; cd ..; cd ..;
+ cd src; cd tools; rm -f *~; cd ..; cd ..;
+ cd tests; cd python; rm -f *.pyc; rm -f *~; cd ..; cd ..;
test:
rm -f ./tests/python/*.pyc
- ./python.exe ./tests/python/runtests.py
+ $(RUNNER) ./python.exe ./tests/python/runtests.py
+
+
+dist: clean
+ mkdir ./$(DIRNAME)-dist
+ cp -R ./makefile ./$(DIRNAME)-dist/
+ cp -R ./*.txt ./$(DIRNAME)-dist/
+ cp -R ./demo ./$(DIRNAME)-dist/
+ cp -R ./doc ./$(DIRNAME)-dist/
+ cp -R ./nunit ./$(DIRNAME)-dist/
+ cp -R ./src ./$(DIRNAME)-dist/
+ cp -R ./tests ./$(DIRNAME)-dist/
+ make
+ cp ./python.exe ./$(DIRNAME)-dist/
+ cp ./*.dll ./$(DIRNAME)-dist/
+ cp ./redist/python22.dll ./$(DIRNAME)-dist/
+ cp -R ./redist/DLLs ./$(DIRNAME)-dist/
+ cp -R ./redist/lib ./$(DIRNAME)-dist/
+ tar czf $(DIRNAME)-dist.tgz ./$(DIRNAME)-dist/
+ rm -rf ./$(DIRNAME)-dist/
dis:
- ildasm Python.Runtime.dll /out=Python.Runtime.il
+ $(ILDASM) Python.Runtime.dll /out=Python.Runtime.il
asm:
- ilasm /dll /quiet \
+ $(ILASM) /dll /quiet \
/resource=Python.Runtime.res /output=Python.Runtime.dll \
Python.Runtime.il
-# Disabled until embedding API is refactored sanely
-#RuntimeTests.dll: Python.Runtime.dll
-# cd tests; cd csharp; make; cd ..; cd ..;
-
-#cstest: RuntimeTests.dll
-# ./nunit/NUnitConsole.exe \
-# Python.Runtime.Tests.AllTests,RuntimeTests.dll
+