[Python-ideas] Making Python more enterprise technology

[Jim Jewett]

On Mon, May 10, 2010 at 10:29 AM, Dj Gilcrease <digitalxero at gmail.com> wrote:
> On Mon, May 10, 2010 at 10:04 AM, Jim Jewett <jimjjewett at gmail.com> wrote:
>> The real concern is that running code can, for example, change the
>> value of sys.stdout, and other programs will see that newly modified
>> value.

> No, no they wouldn't. It is not possible to run multiple python apps
> in a single process, unless you write your own process that is
> importing all these apps and running them in some way.

For example, (the python equivalent of) a web server with multiple
different cgi scripts.  If you say each applet should use its own
python process, then the architecture board will scream about resource
hogging and startup latency, even though that probably is what they do
now for both Perl and Java.

>> And, again, the fact that they wouldn't normally be running in the
>> same process anyhow doesn't seem to be sufficient answer.  In some
>> ways, this is just a FUD argument, but ... monkeypatching really *is*
>> a pain for various audits and separations of authority.  A variant to
>> the python module type that prevents monkeypatching (and using that
>> variant for the builtin libraries) might make some difference.

> Monkeypatching only ever affects your application instance since other
> applications are in other python processes there is no overlap or code
> contamination.

Even if that guarantee were acceptable (but see above), the answer
wouldn't be.  You can't tell from file1 that file2 has monkey-patched
something they both use.  You can't tell that an upgrade to
third-party library foo won't monkey-patch it differently.

Yes, this is true in practice with Java and factories, and you can't
really audit closed-source anyhow, and ... in the end, it doesn't
matter.  Change is scary, so python (or any new infrastructure
technology) has to at least be able to get things right, even when, in
practice,  Java and Perl (or any incumbent technology) do not need to.

-jJ