I'm somewhat surprised that neither your 1 and 2 suggest the possibility of my
using compiled DLLs created from one or more Python modules. That is, if I am
going to deploy a number of Python-coded executables (your 1) and/or DLLs for
use by others (your 2), and each of them references the same
I suppose this conversation should make a distinction, which may make entire
differences disappear.
- the engine the implements the dynamic nature of the language
- the compiler, which takes something written in the language and packages it
into a language-neutral form
- a shell which embeds th
The proliferation of custom config files has been the bane of my existance,
lately. :) And I just spent another night wrestling around with the
propagation of environment variables.
My boss keeps saying that computers and programming are hard. I don't see that
as an excuse for keeping it tha
ith CPython.
From: [EMAIL PROTECTED] on behalf of Jim Hugunin
Sent: Wed 5/4/2005 2:03 PM
To: Discussion of IronPython
Subject: [IronPython] config files vs. env vars and site.py
Right now, IronPython-0.7.* isn't well designed for building Python
applications t
As long as there's a programmatic way to set everything (perhaps with the helper methods on PythonEngine like Jim mentioned), you create any config-based scheme you want.
I always prefer to build programmatic config control first, then call that from my config file parser(s). That way I'm not ha
Right now, IronPython-0.7.* isn't well designed for building Python
applications to be deployed. It's primarily a tool for developer use. Part of
fixing this is making configuration nicer; however, I'm not sure that config
files will be the right final answer. Here's how I see people wanting
