In other words in your opinion Python needs a group of associated companies, that would provide additional support? Isn't that just a cool idea for a bussiness ;-)? -- Filip Gruszczyński

2010/5/9 Dj Gilcrease <digitalxero@gmail.com>:

2010/5/9 Filip Gruszczyński <gruszczy@gmail.com>:

...

For some reason Python seems not to be seen as an enterprise technology unlike Java or .net. ... What Python is lacking?

The only thing lacking from Python / Django to make it "Enterprise Ready" is an SLA (Service Level Agreement) that said enterprise company can pay 200k/y for that gets them nothing.

There are also some dynamic/security tradeoffs that BigCorp would make differently. In python, I can reset the values of sys.*, and it will affect other programs running on the same virtual machine. There isn't really any good way to detect (let alone prevent) this. [Err, unless you count running different processes on different virtual machines, which is what they already do in for Java *in practice*, but ... somehow it isn't acceptable to rely on that.] -jJ

On Mon, May 10, 2010 at 9:44 AM, Bruce Frederiksen <dangyogi@gmail.com> wrote:

On Sun, May 9, 2010 at 11:28 PM, Jim Jewett <jimjjewett@gmail.com> wrote:

...

[...]  In python, I can reset the values of sys.*, and it will affect other programs running on the same virtual machine.

I'm a bit confused by what you are trying to say.

By "virtual machine", do you mean the python byte code interpretor?

Yes.

But generally each instance of the python virtual machine only runs one program.

"Not done in practice" isn't a sufficiently strong argument to get a new infrastructure technology past an architectural board. (A single product which happens to use or embed python, yes. Approval of python for developing new internal products, no.)

... what mechanism are you thinking is used to reset these values? Patching a file in the python library directory?

That would be a problem, but probably acceptable. 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. 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. -jJ

On Mon, May 10, 2010 at 10:29 AM, Dj Gilcrease <digitalxero@gmail.com> wrote:

On Mon, May 10, 2010 at 10:04 AM, Jim Jewett <jimjjewett@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

Jim Jewett <jimjjew...@gmail.com> wrote:

"Not done in practice" isn't a sufficiently strong argument to get a new infrastructure technology past an architectural board.  (A single product which happens to use or embed python, yes.  Approval of python for developing new internal products, no.)

This is just nonsense. I've worked for enterprise orgs that use Python to do exactly that. It's been a long term trend to move away from discrete desktop apps and towards intranet-bound web apps instead. Python is ideal for this use, and none of the security issues you're citing apply.

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.

Pure, unmitigated FUD.

"Stephen J. Turnbull" <step...@xemacs.org> wrote:

Jim didn't say it was *his* concern, just that he has so far been at best partially successful in convincing people that it's no more an issue for Python than for incumbent platforms.  

Jim said:

There are also some dynamic/security tradeoffs that BigCorp would make differently. In python, I can reset the values of sys.*, and it will affect other programs running on the same virtual machine.

He doesn't say "my employers believe", he quite clearly states that _he can modify sys.* and it will be picked up by other programs. The fact that the Python interpreter _doesn't work that way_ he dismisses as irrelevant shortly after, which I just cannot follow. If anyone can show me how I can run one python program and have it modify the sys.stdout of an existing running python process without explicitly coding the latter to allow for it, please, I'd love to be enlightened.

Stephen J. Turnbull wrote:

What that means to the architecture board is that they are going to have to write up some coding standards about globals, when you can create them, when you can touch them, what you can do when you do mess with them, what kind of cleanup is required, and how and where you must document all of the above when you do it. I'm not at all surprised that they throw up their hands and say "no, thanks".

From my experience, Python most effectively makes its way into organisations the way Linux did originally: developers are able to get approval to use it at a fairly low level because it doesn't cost anything, the licensing is more than reasonable and it will get the job done. Once it is in the door and being used for "support" tasks, it slowly makes its way closer and closer to core internal business applications (as different tasks come up, developers do initial

It's also the reason AppEngine cuts out a bunch of things to make it easier to keep apps under control:) prototypes in Python to try out functionality, then ask the obvious question "hey, how about we do the real thing in Python as well?"). Java and .NET have large organisations behind them with significant marketing budgets pushing them as the programming platform du jour. Python, like Linux before Red Hat started making money and the enterprise server hardware vendors got involved, relies more on word of mouth and unpaid advocacy. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

"Stephen J. Turnbull" <step...@xemacs.org> wrote:

What that means to the architecture board is that they are going to have to write up some coding standards about globals, when you can create them, when you can touch them, what you can do when you do mess with them, what kind of cleanup is required, and how and where you must document all of the above when you do it.  I'm not at all surprised that they throw up their hands and say "no, thanks".

... So a fictional architecture board's imagined opinion somehow trumps the actual concrete experience I've had with working with Python in an enterprise environment? Wow. Good luck with this thread. I'm not entirely sure what the point of it is, but I'm sure you'll all come to some amazing conclusions by the end of it.

On 2010-05-11, David Stanek wrote:

2010/5/9 Filip Gruszczyński <gruszczy@gmail.com>:

...

For some reason Python seems not to be seen as an enterprise technology unlike Java or .net. Do you think there any steps that could be taken, to change this opinion? I love Python, but all job offers I can find at the moment are web development. At my company we use Python a lot, but that's only because my lead is a very sensible person and sees python potential and me and my friend are python enthusiasts. Anyway, beside one Python + Qt project we mostly use Django for projects. How can this be changed? What Python is lacking?

I believe that marketing, or lack of, has played a big role in Python's acceptance. Java and C# have a big advantage by being promoted so heavily by large, well-known companies. When I talk to people I know in the enterprise space they don't understand exactly what Python is or what it can be.

The pointy haired managers know that in a pinch they can get Java/C# guys because there are so many. Outsourcing (I personally don't like) is also much easier with Java/C#.

As far as I'm aware no big company specifically promoted or promotes C++ (apart from those selling commercial compilers & related tools), yet C++ is still very widely used. Naturally, C++'s C-compatibility has been a big help, but most languages nowadays are C compatible (at least as far as being able to access C functions inside C libraries, and this includes Python of course). I think that one of the big wins for C++ (and C) was ISO standardization. Companies that use C++ know that they can get compliant compilers which gives them long term confidence that C++ is safe to invest in. (Of course Pascal is also standardized, and it hasn't helped the language at all.) Unfortunately, C++ has developed at a glacial pace in the last decade, with a much too long gap between standards. (They are hoping to get the gap down to five years _after_ the 2011 or 2012 standard is ratified!) If Python were to be standardized it would become much more visible and a much safer corporate bet. Such a process wouldn't be easy and I doubt anyone would want to update the standard too often. One possible way would be to standardize one particular version, but not the next two minor releases. For example, standardize 3.2, but not 3.3 or 3.4, then standardize 3.5, but not 3.6 or 3.7, and so on. This would mean that the standardization effort would take place about every four years (and which would only affect those involved in the standardization process). There would however, be a cost to the development community: maintaining the standardized version (e.g., bug & security fixes) until it is superceded. My 2c on "enterprise" Python;-) -- Mark Summerfield, Qtrac Ltd, www.qtrac.eu C++, Python, Qt, PyQt - training and consultancy "Advanced Qt Programming" - ISBN 0321635906

Mark Summerfield writes:

As far as I'm aware no big company specifically promoted or promotes C++

That's because the U.S. government dismembered it and in the process kneecapped a national treasure. :-P

If Python were to be [ISO] standardized it would become much more visible and a much safer corporate bet.

Perl managed without it, and AFAIK there is no ISO or ANSI Java, either (the #3 Google hit was "Sun Drops ISO Java Standards Effort For Good" from 1999). Admittedly, EMCAscript is there, but that came afterward, pushed by enterprises that had already adopted Javascript, and wanted to stop the Netscape vs. Microsoft whipsaw. In fact, Python not only has an excellent standard, but it has excellent testing of the standard, what with 4 major implementations aiming for conformance IIUC, plus assorted near-implementations such as Cython and Stackless. I suspect that a well-run marketing campaign by the PSF, starting by trademarking "Standard Python" and getting some funding to set up a conformance testing certification program, would do wonders at not such great expense.

Mark Summerfield writes:

On 2010-05-12, Stephen J. Turnbull wrote:

...

In fact, Python not only has an excellent standard, but it has excellent testing of the standard, what with 4 major implementations aiming for conformance IIUC, plus assorted near-implementations such as Cython and Stackless. I suspect that a well-run marketing campaign by the PSF, starting by trademarking "Standard Python" and getting some funding to set up a conformance testing certification program, would do wonders at not such great expense.

I'm sure you're right, but I guess it would be quite an undertaking.

I'm not at all sure I'm right<wink>, but the point is that it need not be such a huge undertaking. There are some governments out there who might be willing to supply some funding, and perhaps some consultancies might like to get into the certification game for fun and profit. It wouldn't be as big as deal as ISO, of course, but you get what you pay for (even if it's just a fancier rubber stamp!) OTOH, you might attract the attention of an on-average smarter crowd of PHBs this way, even if it's smaller than ISO certification would get. That has its advantages, too.