Cross Platform Python
Cross Platform Python
There are several ways to ship Python programs on Windows:
1) Require that the user have Python installed and their path configured. This is not recommended, since they also need to install all required libraries such as Numpy or Pygame. Also, this becomes more difficult with Python 2/3, since only one can be the default Python installation at a time.
2) Use py2exe or a similar alternative to compile the scripts into a single executable file. The biggest inconvenience with this is needing to recompile the program every time a change is made, and the source code is not shipped with the product.
3) Use Portable Python to ship the correct instance of Python and libraries with your product. This adds at least 30MB to the download, but allows you to ship the .py files directly, allowing end-user modification of the code.
What are the options on Macs? I know Macs come with Python, but what about libraries such as Numpy and Pygame? Python 2 vs 3?
1) Require that the user have Python installed and their path configured. This is not recommended, since they also need to install all required libraries such as Numpy or Pygame. Also, this becomes more difficult with Python 2/3, since only one can be the default Python installation at a time.
2) Use py2exe or a similar alternative to compile the scripts into a single executable file. The biggest inconvenience with this is needing to recompile the program every time a change is made, and the source code is not shipped with the product.
3) Use Portable Python to ship the correct instance of Python and libraries with your product. This adds at least 30MB to the download, but allows you to ship the .py files directly, allowing end-user modification of the code.
What are the options on Macs? I know Macs come with Python, but what about libraries such as Numpy and Pygame? Python 2 vs 3?
Re: Cross Platform Python
1) OS X comes with python shipped. On 10.8, I have python 2.7.2 running, on my (really old, last updated 5 years ago) 10.5 machine, I have 2.5.1 running. 10.6 - 10.7 are likely in between somewhere. Presumably Python 3.x isn't shipped due to compatibility reasons out of Apple's control. There is a dynamic linked library (a framework) on the machine in /System/. Numpy comes installed too, I think. Also, apps never require the user to install a dependence beforehand, anyway.
2) OS X has py2app. Eg: write a pygame application, package up the python script into an app bundle, and it will take care of dependencies, and it will probably use system version of Python installed. py2app is a last step for distributing. Certainly you don't need to use it for testing.
3) You could go the route of building python from source and spitting out a static or shared object file. It'd be several megabytes, but not near 30 I imagine/hope. If you want to use a third party library, I imagine that it's possible to put the the library in the app bundle and import the module(s) as needed.
4) There is PyObjc, a bridge between Python and Objective-C allowing you to use and extend Obj-C classes. This is possible because of ObjC's dynamic nature. Again, probably uses system Python framework. Not sure how widely used this is, but I've used it for my memory modding template.
2) OS X has py2app. Eg: write a pygame application, package up the python script into an app bundle, and it will take care of dependencies, and it will probably use system version of Python installed. py2app is a last step for distributing. Certainly you don't need to use it for testing.
3) You could go the route of building python from source and spitting out a static or shared object file. It'd be several megabytes, but not near 30 I imagine/hope. If you want to use a third party library, I imagine that it's possible to put the the library in the app bundle and import the module(s) as needed.
4) There is PyObjc, a bridge between Python and Objective-C allowing you to use and extend Obj-C classes. This is possible because of ObjC's dynamic nature. Again, probably uses system Python framework. Not sure how widely used this is, but I've used it for my memory modding template.
I am no longer active to Halo or MGM, and don't guarantee a response on the forums or through email. I will however linger around the discord room for general chatting. It's been fun!
Re: Cross Platform Python
Is this one of the easier solutions for creating a Cocoa GUI for a Python program? I imagine there are also Cocoa bindings for Python.nil wrote:4) There is PyObjc, a bridge between Python and Objective-C allowing you to use and extend Obj-C classes. This is possible because of ObjC's dynamic nature. Again, probably uses system Python framework. Not sure how widely used this is, but I've used it for my memory modding template.
Re: Cross Platform Python
Yes if you want to create a Cocoa application using Python, PyObjc is the way to go. Cocoa is written in ObjC, hence these are the "bindings."WaeV wrote:Is this one of the easier solutions for creating a Cocoa GUI for a Python program? I imagine there are also Cocoa bindings for Python.nil wrote:4) There is PyObjc, a bridge between Python and Objective-C allowing you to use and extend Obj-C classes. This is possible because of ObjC's dynamic nature. Again, probably uses system Python framework. Not sure how widely used this is, but I've used it for my memory modding template.
I am no longer active to Halo or MGM, and don't guarantee a response on the forums or through email. I will however linger around the discord room for general chatting. It's been fun!
Re: Cross Platform Python
Moving from C# to Python for my project, I'm a bit bummed out about losing PLINQ for concurrency. Fortunately, I managed to find a library which may give me a decent alternative - ZeroMQ.
Here are some statements about ZeroMQ I found on a few sites.
Here's a potential architecture diagram:
The Mac version would use the standard PyObjc bindings, and the Windows version would use IPC to communicate between CPython and the CLR.
The separate CPython boxes represent separate instances of Python communicating with IPC.
Cython is a neat C-extension to Python which allows optional static typing within Python for performance and FFI calls. It allows the use of C types such as compound structs, pointers, and enums. That should make grokking Halo's file format easier.
Here are some statements about ZeroMQ I found on a few sites.
- ZeroMQ looks like an embeddable networking library but acts like a concurrency framework.
- It gives you sockets that carry whole messages across various transports like in-process, inter-process, TCP, and multicast.
- It’s fast enough to be the fabric for clustered products.
- Its asynchronous I/O model gives you scalable multicore applications, built as asynchronous message-processing tasks.
- It has a score of language APIs and runs on most operating systems making it great for homogeneous environments.
Here's a potential architecture diagram:
The Mac version would use the standard PyObjc bindings, and the Windows version would use IPC to communicate between CPython and the CLR.
The separate CPython boxes represent separate instances of Python communicating with IPC.
Cython is a neat C-extension to Python which allows optional static typing within Python for performance and FFI calls. It allows the use of C types such as compound structs, pointers, and enums. That should make grokking Halo's file format easier.
Re: Cross Platform Python
By the way, have you looked at Mono and Cocoa together? Also, this may be a lot of work =P. In the end, you'd want the UI to look native on each platform (so basically not much is shared here). Other non-os-dependent code could be shared. Part of MVC paradigm I suppose.
I am no longer active to Halo or MGM, and don't guarantee a response on the forums or through email. I will however linger around the discord room for general chatting. It's been fun!
Re: Cross Platform Python
Yes, there is a project called "MonoMac" which is Cocoa bindings for C#, which would require less of a leap. Either way, the Mac GUI would have to be developed separately from the WPF one for Windows.nil wrote:By the way, have you looked at Mono and Cocoa together? Also, this may be a lot of work =P. In the end, you'd want the UI to look native on each platform (so basically not much is shared here). Other non-os-dependent code could be shared. Part of MVC paradigm I suppose.
There's plenty of potential for code sharing. I do have an MVC-like architecture: http://i.imgur.com/Y33CmnC.png
This is basically view = green, controller = blue and purple, model = yellow. The startup 'layer' is very small. Everything except the view is sharable - no logic about how to deal with Halo is contained in the view; all it does is display data from the model and trigger commands in the controller.
After I made this diagram I decided that rather than have all edits be implemented through various services, it might be better to have some sort of scripting language that all edits are performed through. I finally settled on Python for scripting, but I'm beginning to find that IronPython might not fit my needs due to certain library incompatibilities.
Plus the backend was due for rewriting, in C# or F# if not Python. Learning ZeroMQ seems appealing. Other than the backend, there's not much of Quickbeam that's worth saving.
Re: Cross Platform Python
py2app and py2exe have been the go-to solution for freezing Python 2 programs into executables for Mac and Windows respectively, but only have experimental Python 3 suport.
but... good news! Apparently cx_freeze works on both platforms (as well as Linux) and supports Python 2 and 3.
but... good news! Apparently cx_freeze works on both platforms (as well as Linux) and supports Python 2 and 3.
Who is online
Users browsing this forum: No registered users and 2 guests