[Zope-CVS] CVS: PythonNet - README.txt:1.5 makefile.mono:1.3

Brian Lloyd brian at zope.com
Sat Aug 9 00:30:23 EDT 2003


Update of /cvs-repository/PythonNet
In directory cvs.zope.org:/tmp/cvs-serv4904

Modified Files:
	README.txt makefile.mono 
Log Message:
p2 updates

=== PythonNet/README.txt 1.4 => 1.5 ===
--- PythonNet/README.txt:1.4	Fri Aug  1 10:30:08 2003
+++ PythonNet/README.txt	Fri Aug  8 23:29:46 2003
@@ -1,23 +1,25 @@
-Python Scripting For .NET
+Python for .NET
 
-  This is an experimental integration of CPython with the .NET Common 
-  Language Runtime. If you have questions, comments or huge bags 'o cash, 
-  send them to brian at zope.com :)
+  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.
+
+  The current released version of Python for .NET is preview-2.
 
 
   **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.
+    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.
 
 
   **What is the license?**
@@ -32,22 +34,21 @@
 
   **Does it work with Mono?**
 
-    Mostly :) Some things to note about running under Mono:
-
-    One, it is not currently possible to *build* PythonNet 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 
-    PythonNet directory so that Mono can find and load the Python shared 
-    library.
-
-    Third, Mono is under heavy development - while most of the PythonNet 
-    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.
+    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?**
@@ -55,7 +56,7 @@
     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 
+    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, 
@@ -66,7 +67,7 @@
 
       - 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 
+        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.
@@ -86,8 +87,8 @@
   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.
+    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 
@@ -95,7 +96,7 @@
     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.
+    it would also require far more work than the current approach.
 
 
   Is This Related To ActiveState's Python.NET Work?
@@ -187,6 +188,11 @@
           p = Point(5, 5)
 
 
+      You can also subclass managed classes in Python. See the 'helloform.py' 
+      file in the '/demo' directory of the distribution for a simple Windows 
+      Forms example that demonstrates subclassing a managed class.
+
+
     **Fields And Properties**
 
       You can get and set fields and properties of CLR objects just as if 
@@ -311,12 +317,6 @@
           items[0, 2, 3]
 
 
-    **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**
 
@@ -339,15 +339,19 @@
       a logical equivalent in Python are instances of managed types.
 
       Note that all strings returned from CLR methods, properties, etc. 
-      are returned as unicode.
+      are returned as unicode, for the sake of my sanity :)
 
 
     **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 PythonNet 
-      assembly will demand to run, but it will 
+
+      PythonNet requires reflection permission, along with a whole host of 
+      other permissions for calling unmanaged code, etc. Because Python code 
+      can open files and do many other things without the knowledge or consent 
+      of the CLR, you should restrict use of the Python assembly to trusted 
+      code.
 
 
   **Does it support embedding?**
@@ -371,6 +375,7 @@
     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.mono 1.2 => 1.3 ===
--- PythonNet/makefile.mono:1.2	Thu Jul 24 19:59:23 2003
+++ PythonNet/makefile.mono	Fri Aug  8 23:29:46 2003
@@ -1,6 +1,10 @@
 # Makefile for the PythonRuntime .NET assembly and tests. Thanks to
 # Camilo Uribe <kmilo at softhome.net> for contributing Mono support.
 
+# WARNING: this makefile cannot currently build the Python runtime
+# dll under mono, due to use of attributes that the mono assembler / 
+# disassembler doesn't yet support.
+
 DIRNAME=PythonNet
 RUNNER=mono
 ILDASM=monodis
@@ -32,7 +36,7 @@
 	rm -f Python.Runtime.res;
 	rm -f ./CallConvUtil.exe;
 
-Python.Test.dll: Python.Runtime.dll
+Python.Test.dll:
 	cd src; cd testing; \
 	$(CSC) /nologo /target:library /out:../../Python.Test.dll \
 	/reference:../../Python.Runtime.dll \
@@ -48,7 +52,7 @@
 
 
 clean:
-	rm -f python.exe Python*.dll Python*.il Python*.il2 Python*.res
+	rm -f python.exe Python.Test.dll Python*.il Python*.il2 Python*.res
 	rm -f CallConvUtil.exe
 	rm -f ./*~
 	cd src; cd console; rm -f *~; cd ..; cd ..;




More information about the Zope-CVS mailing list