Python in the enterprise: Pros and cons
builder
the enterprise? Here are the advantages and disadvantages of using
Python in the corporate environment.
http://builder.com.com/article.jhtml?id=u00420020709DGS01.htm
Trent Mick
> The cons:
> ...
> - Absence of a commercial support point, even for an Open Source project
> (though this situation is changing)
> ...
Perhaps you missed:
http://www.ActiveState.com/Products/PythonDirect/
Cheers,
Trent
--
Trent Mick
Tre...@ActiveState.com
mk...@yahoo.com
"Smaller pool of Python developers compared to other languages, such as Java"
Some commercial tool vendors, who have thousands of developers, still have bugs
in their products that are many years, and product versions, old. It is not the
size of your developer base that is important, it is how you use it.
"Absence of a commercial support point, even for an Open Source project (though
this situation is changing)"
Perl, Apache? Lack of a singluar commercial support entity does not seem to have
hurt them. With most popular open source tools, support of a variety of types
can be found. The thing with Python (and Perl, etc.) is that you do not have to
pay for support, unless you really want to.
Funny thing is, the support thing seems to get brought up so often, that I
believe that it's importance is somewhat inflated. In my experience, support for
a language is not nearly as critical is it may be for a commercial database
system, for example. If my code does not work, I can re-write it in a way that
it will work, to work around a language implementation flaw. In over a decade of
developing software, I can recall a single instance where _commercial_
programming language support was needed - and it was not for an open source
language. Anyone care to guess who the vendor of the language product was?
"Software performance (though benchmarks repeatedly demonstrate Python is
comparable to Java in most applications)"
Then why is this a problem? Java is very obvious in Enterprise level
envrionments. Thus if in "most" situations, if Python performance is comparable
to Java, and Java's performance is accepted, should not Python's?
There will always be a segment of the market who will choose their tools based
on how many other people use them (sheep), and not be concerned on how suited to
the task or efficient the tools are. Some of us prefer to be the wolves.
David LeBlanc
* Smaller pool of Python developers compared to other languages, such as
Java
-- Easier learning curve compared to other languages such as Java, C, C++,
Perl, Tcl and Ruby; especially so for people coming from any of those
languages. Python is just plain easy to learn.
* Lack of true multiprocessor support
-- Heh. That's not really true either. Python is no better and no worse then
any other application program wrt to multiprocessor usage. What the author
probably was referring to here is Python's lack of multi-processor
multi-threading - i.e. true parallel computation. Know many non-specialized
languages that can or do exploit multi-processor multi-threading? There are
even OS dependencies: Win32 OS's (NT, 2k, XP) will not spread applications
across processors unless your program causes it to explicitly (this is at
least true on retail 2 processor maximum systems). Linux OTOH, does so.
* Absence of a commercial support point, even for an Open Source project
(though this situation is changing)
-- I think you haven't noticed the forest for all the trees. While there is
no dominant well known Python Services Provider (maybe we could buy Anderson
Consulting cheap ;-)), there are quite a number of smaller companies and
individuals offering Python support and consulting. Digital Creations,
Python Labs, Pythonware and Orbtech come to mind and there are many others.
* Software performance (though benchmarks repeatedly demonstrate Python is
comparable to Java in most applications)
-- "Python is comparable to Java" is probably a con - Python far surpasses
Java in the shortness of time spent going from "hmmm ..." to "run ...". If
you're comparing clock cycles, then you're saying an open source development
project has done what a multi-billion dollar company with 100's of
developers has done (that's a bit unfair - Python probably has more
developers (including "battery" developers) on it then does Java). Python
can and most likely will get faster and even more popular, but I'm not sure
the same can be said for Java.
* Lack of prepackaged solutions
-- Take a look at the Python foundry on SourceForge. Browse the
comp.lang.python.announce archives. Spend an afternoon in the Vaults of
Parnassas, Python's defacto standard repository/catalog for contributed
software. Search for "python applications" on Google or Yahoo. Try "python
<application name>" for whatever type of application you're looking for and
see what comes up. Lack of channels for promoting Python applications
doesn't mean they don't exist.
* Python's obscurity in development shops
-- We don't WANT to take over the COBOL shops ;o)! I suspect most Linux and
Windows programmers have heard of Python and it would not surprise me to
know that a lot of them where using it internally where it's below the radar
of the people who poll language use (Dataquest, Gartner Group?). IBM, HP and
Intel use Python!
* Database access layer limitations
-- Ok, I agree that maybe this could be better "out of the box", but there
are good ODBC wrappers for Python from 3rd parties. ODBC is one of the few
specs that Microsoft got right enough for it to find it's way to the Linux
world.
* Documentation gaps
-- This was recently discussed on comp.lang.python. There are at least 27
books dealing with Python or Python in specific applications. The "in the
box" documentation is ackward to use but reasonably comprehesive (tutorial
aside - the best basic introduction is the book "Learning Python" by Mark
Lutz). There are at least 2 full books for Python online: DiveIntoPython and
"How To Think Like A Computer Scientist" (using Python), and many other
online resources available through Python.org.
* Absence of GUI and teamwork tools
-- There two commercial tools for wysiwyg tkinter development, one of which
is PythonWorks from Pythonware. Do CVS and Subversion count as teamwork
tools? They do solve the source management part. MoinMoin Wiki software will
solve the team interaction part of the equation, and there are chat packages
out there, including a Jabber client for instant messaging on all the
popular IM networks. It's a product opportunity for someone to integrate all
the tools into a cohesive whole, but all the parts seem to be there...
-----------
The one thing that has come to mind from writing this as a con for Python is
the lack of channels for widespread dissemination of information about
commercial software applications, support and consulting. Python does need
better publicizing in the marketplace. Python.org provides such a focus for
information about the language, but provides little beyond a jobs board for
the marketplace. It would be nice to see a registry of products and services
that use or support Python.
My conclusion is that Python is entirely ready for the enterprise - and it's
already there!
David LeBlanc
Seattle, WA USA
Paul Rubin
> * Lack of true multiprocessor support
>
> -- Heh. That's not really true either. Python is no better and no worse then
> any other application program wrt to multiprocessor usage. What the author
> probably was referring to here is Python's lack of multi-processor
> multi-threading - i.e. true parallel computation. Know many non-specialized
> languages that can or do exploit multi-processor multi-threading? There are
> even OS dependencies: Win32 OS's (NT, 2k, XP) will not spread applications
> across processors unless your program causes it to explicitly (this is at
> least true on retail 2 processor maximum systems). Linux OTOH, does so.
I thought NT could use multi-processor multi-threading. I don't see
any issue about having to tell it to. If you could tell Python to use
multiple processors, that would count too.
> * Software performance (though benchmarks repeatedly demonstrate Python is
> comparable to Java in most applications)
>
> -- "Python is comparable to Java" is probably a con - Python far surpasses
> Java in the shortness of time spent going from "hmmm ..." to "run ...". If
> you're comparing clock cycles, then you're saying an open source development
> project has done what a multi-billion dollar company with 100's of
> developers has done (that's a bit unfair - Python probably has more
> developers (including "battery" developers) on it then does Java). Python
> can and most likely will get faster and even more popular, but I'm not sure
> the same can be said for Java.
There are almost certainly more people writing Java stuff than Python
stuff. Python wins big in development speed and development speed is
important, but it's not always the only thing. Sometimes you care how
fast your program runs AFTER you've written it. And native-code Java
compilers like gcj completely beat the pants off Python in terms of
execution speed. There are some projects like psyco which aim to
narrow that gap, but they're not yet ready for prime time.
> * Lack of prepackaged solutions
>
> -- Take a look at the Python foundry on SourceForge. Browse the
> comp.lang.python.announce archives. Spend an afternoon in the Vaults of
> Parnassas, Python's defacto standard repository/catalog for contributed
> software. Search for "python applications" on Google or Yahoo. Try "python
> <application name>" for whatever type of application you're looking for and
> see what comes up. Lack of channels for promoting Python applications
> doesn't mean they don't exist.
Regardless of that, lots of stuff has been written in Java that's
never been written in Python. Where's the Python TLS stack with
certificate management? Where are the Enterprise Python Beans? Where
is the JCE-like Python cryptography library with hardware service
providers (answer to that one: I'm writing it but it has a ways to
go)? Where's the Python ODBC interface (ans: it exists but you have
to pay for it)? The list goes on, and that's just Java.
> * Documentation gaps
>
> -- This was recently discussed on comp.lang.python. There are at least 27
> books dealing with Python or Python in specific applications. The "in the
> box" documentation is ackward to use but reasonably comprehesive (tutorial
> aside - the best basic introduction is the book "Learning Python" by Mark
> Lutz).
Yes, those are documentation gaps. You have to actually go out buy
chunks of dead tree pulp in order to use this documentation, and then
let it encroach heavily into your working/living space if you want to
keep it around for future reference. To me, these problems greatly
decreases its value of such docs. Java's online docs are far superior
to Python's. There are also a lot more books about Java, but I don't
care about those for the same reason I don't care about Python books.
> There are at least 2 full books for Python online: DiveIntoPython and
> "How To Think Like A Computer Scientist" (using Python), and many other
> online resources available through Python.org.
These are tutorials and neither of them attempts to be complete references.
> * Absence of GUI and teamwork tools
>
> -- There two commercial tools for wysiwyg tkinter development, one of which
> is PythonWorks from Pythonware. Do CVS and Subversion count as teamwork
> tools? They do solve the source management part. MoinMoin Wiki software will
> solve the team interaction part of the equation, and there are chat packages
> out there, including a Jabber client for instant messaging on all the
> popular IM networks. It's a product opportunity for someone to integrate all
> the tools into a cohesive whole, but all the parts seem to be there...
I'm not too impressed by any of those but I'm not impressed by Swing
or AWT either, so it balances out.
> The one thing that has come to mind from writing this as a con for Python is
> the lack of channels for widespread dissemination of information about
> commercial software applications, support and consulting. Python does need
> better publicizing in the marketplace. Python.org provides such a focus for
> information about the language, but provides little beyond a jobs board for
> the marketplace. It would be nice to see a registry of products and services
> that use or support Python.
>
> My conclusion is that Python is entirely ready for the enterprise - and it's
> already there!
Python is ready for some applications and getting there for others.
It has a lot of virtues and to be clear about it, I like Python better
than Java for most purposes. However, Python's advocates often don't
acknowledge that there are still areas where Python genuinely does
fall behind. We need to stay aware of Python's shortcomings so we can
acknowledge them and/or fix them.
Max Ischenko
builder wrote:
After reading their ah...well...stupid
article about XP, I won't even bother to look at this.
--
You have to think in a language to write programs in it,
and it's hard to want something you can't describe.
-- Paul Graham.
Martijn Faassen
[snip snip]
> Python is ready for some applications and getting there for others.
> It has a lot of virtues and to be clear about it, I like Python better
> than Java for most purposes. However, Python's advocates often don't
> acknowledge that there are still areas where Python genuinely does
> fall behind. We need to stay aware of Python's shortcomings so we can
> acknowledge them and/or fix them.
I think that this is a very good point to make. I thought the
article to be a pretty fair assessment overall (though one can quibble over
some points), and it certainly wasn't negative about Python.
Python has a lot of good stuff going for it, but it's not perfect
either.
Quibble: I've been using ODBC in PythonWin since '98 and
it's quite free. ;) I'm sure it's limited but sufficient for the little
things I do with it.
Regards,
Martijn
--
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?
Alex Martelli
...
> Yes, those are documentation gaps. You have to actually go out buy
> chunks of dead tree pulp in order to use this documentation, and then
> let it encroach heavily into your working/living space if you want to
> keep it around for future reference. To me, these problems greatly
Untrue: safari.oreilly.com can give you access to many books without
any tree slaying and without requiring you to set a foot out of the
door -- and your working/living space remains uncluttered, too.
You do have to pay O'Reilly some money to use the service, though:-).
Alex
Kim Petersen
> * Python's obscurity in development shops
>
> -- We don't WANT to take over the COBOL shops ;o)! I suspect most Linux and
> Windows programmers have heard of Python and it would not surprise me to
> know that a lot of them where using it internally where it's below the radar
> of the people who poll language use (Dataquest, Gartner Group?). IBM, HP and
> Intel use Python!
>
Why not? (in fact i've been hired to do exactly that - hehe) From my
point of view, Python encompasses a lot of the elements that the COBOL
developers want (and some of what they always claimed COBOL to have ....
readability!).
* We have portability (surpassing most COBOL variants)
* We have speed (at least as much speed as a COBOL developer will expect)
* We have large scale database integration (via PyDBI (or what its called)
* We have portable GUI's, that are extremely easy to use comparedly.
Learning Python is straight forward, and doesn't scare of a COBOL
programmer in the way that C++ or Java would.
Bo M. Maryniuck
> Python has many fans in the open source community, but is it ready for
> the enterprise?
--
Sincerely yours, Bogdan M. Maryniuck
"...Deep Hack Mode--that mysterious and frightening state of
consciousness where Mortal Users fear to tread."
(By Matt Welsh)
Bo M. Maryniuck
> After reading their ah...well...stupid
> article about XP, I won't even bother to look at this.
You are right. Better go bear and develope forward. :)
--
Sincerely yours, Bogdan M. Maryniuck
"I once witnessed a long-winded, month-long flamewar over the use of
mice vs. trackballs...It was very silly."
(By Matt Welsh)
Armin Steinhoff
There are not mentioned the GUI tools wxPython and PyQt !
We are buidling industrial applications with PyQt (and the Qt
Designer) and the embedded SQL databases 'gadfly' and 'PySQLite'.
These applications are system independent and are working under
QNX6.2, Linux and Windows.
Bo M. Maryniuck
> These applications are system independent and are working under
> QNX6.2, Linux and Windows.
BTW, can You explain how to use QT/Python under Windows for non-commertial
soft? I've tried and I've fault... What I should download from TrollTech to
make my hello_world.py run QT widgets on Bill's platform? :/
Note, that I have only Windows OS (no VisualBasic, no VC++, no Borland stuff
etc). Only notepad.exe :) In other hand, I successfully use wxWindows on M$
Windows and Linux OS. And no problem tu run Python / QT 3.0 on Linux box. So
seems that QT is quite hard to install on Windows. :|
--
Sincerely yours, Bogdan M. Maryniuck
"World domination. Fast"
(By Linus Torvalds)
Tim Peters
> Python has many fans in the open source community, but is it ready for
> the enterprise?
[Bo M. Maryniuck]
> What the buzzword "the enterprise" is (as other buzzwords, aka
> XML, Java etc)?
It's an especially annoying American buzzword for "business use, as opposed to consumer, research, or educational use". Your enterprise-ready software is primed to take on the challenge of synergizing mission-critical business logic in empowering ways. IOW, it computes the sales tax right more often than not <wink>.
to-the-next-level-going-forward-ly y'rs - tim
Boudewijn Rempt
> On Thursday 11 July 2002 11:03, Armin Steinhoff wrote:
>> These applications are system independent and are working under
>> QNX6.2, Linux and Windows.
>
> BTW, can You explain how to use QT/Python under Windows for non-commertial
> soft? I've tried and I've fault... What I should download from TrollTech
> to make my hello_world.py run QT widgets on Bill's platform? :/
>
> Note, that I have only Windows OS (no VisualBasic, no VC++, no Borland
> stuff etc). Only notepad.exe :) In other hand, I successfully use
> wxWindows on M$ Windows and Linux OS. And no problem tu run Python / QT
> 3.0 on Linux box. So seems that QT is quite hard to install on Windows. :|
>
You can _only_ use Qt 2.x on Windows without buying a Qt license. You can
either buy BlackAdder, which includes everything you need, or download
the non-commercial Qt for Windows, and the pre-compiled PyQt bindings (if
Phil still makes these available). There are a few nasty bugs in the
non-commercial version of Qt, though.
Links:
ftp://ftp.trolltech.com/qt/non-commercial
http://www.riverbankcomputing.co.uk/download/PyQt/
--
Boudewijn Rempt | http://www.valdyas.org
Bo M. Maryniuck
> > What the buzzword "the enterprise" is?
> It's an especially annoying American buzzword for "business use, as opposed
> to consumer, research, or educational use".
Ah, Bill Gates buzzword again. Excuse me... Therefore according to this
explanation, seems that LISP or Scheme are enterprise too, except of
"high-phrases" AKA "...our very educated managers...", "...our high
business...", "...our success in the market..." and so on.
--
Sincerely yours, Bogdan M. Maryniuck
We are using Linux daily to UP our productivity - so UP yours!
(Adapted from Pat Paulsen by Joe Sloan)
Paul Boddie
>
> Regardless of that, lots of stuff has been written in Java that's
> never been written in Python. Where's the Python TLS stack with
> certificate management? Where are the Enterprise Python Beans?
In the Python community, it's almost seen as a virtue that people
don't write things that they don't need. Whilst some things held up in
language comparisons aren't needed in Python because of the language's
(and/or standard library's) inate capabilities, other things do
apparently point to the fact that Python isn't being used in certain
application areas.
The subject of Enterprise Beans is a contentious hybrid of these two
positions in the context of Python. Some might argue that EJB is a
necessary and well-informed framework which can help significantly in
the implementation of software for business; others might suggest that
it's a bloated standard that few people bother to take full advantage
of. Consequently, one might find Python in use either imitating EJB or
instead competing with "sub-EJB" systems written in Java or other
languages which don't support such frameworks.
However, one thing which is, in my opinion, important about EJB and
other Java technologies is the standardisation that comes with them.
With Java, developers don't have to choose an application server and
then use an API specific to that server; instead, they can choose an
API and expect most servers to do a reasonable job of supporting it
(even though the old "write once, test everywhere" curse still applies
somewhat).
Thankfully, Python has some standards in some technology areas, such
as SQL and XML. Without even an elementary level of standardisation,
Python would be as attractive as C++ for these technologies, and
having done some work in C++ and XML recently, I can confirm that it
isn't fun to use C++ in that area (whereas it is fun to use Python
with XML) and it would be a nightmare to migrate to different
libraries (whereas it would be much easier, if not completely trivial,
in Python).
> Java's online docs are far superior
> to Python's. There are also a lot more books about Java, but I don't
> care about those for the same reason I don't care about Python books.
Some Java documents are very good, but other documents (in the maze of
java.sun.com) are of fairly limited use. Moreover, the further one
roams from Sun towards third parties, the worse the situation gets:
lots of people with problems, no-one with solutions.
> Python is ready for some applications and getting there for others.
> It has a lot of virtues and to be clear about it, I like Python better
> than Java for most purposes. However, Python's advocates often don't
> acknowledge that there are still areas where Python genuinely does
> fall behind. We need to stay aware of Python's shortcomings so we can
> acknowledge them and/or fix them.
Python is in the enterprise, even if its presence owes much to
stealth, and I think many would be surprised how much usage Jython
gets without much publicity in the usual Python community circles.
Still, we need to be more self-critical and more committed to remove
the tedious obstacles in the existing standards (portable database
code is still a challenge), yet we should, in addition, continue to
look for genuinely innovative solutions which don't necessarily owe a
great deal to mainstream enterprise standards.
Paul
Cameron Laird
David LeBlanc <whi...@oz.net> wrote:
.
.
.
>My conclusion is that Python is entirely ready for the enterprise - and it's
>already there!
.
.
I read Ms. Fraser's article more charitably than
others who have been following up here. I thought
she made clear that she's reporting on both tech-
nical reality and organizational perception. So,
for example, it doesn't matter (boy, can I testify
it doesn't matter) that Python is, for example,
as fast as Java, if a customer is incapable of
retaining that fact.
My main point, though, is to encourage the folks
working on Pyadvocacy pages. In particular, yes,
it's absolutely true that Python is already in the
enterprise, and thriving. I know, for example, of
companies which provide goods and services at
rates of over a million customer-contacts per
month, in which Python plays a central role.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Cameron Laird
Bo M. Maryniuck <b.mar...@forbis.lt> wrote:
>On Thursday 11 July 2002 11:47, Tim Peters wrote:
>> > What the buzzword "the enterprise" is?
>osed
>> to consumer, research, or educational use". =20
>
>Ah, Bill Gates buzzword again. Excuse me... Therefore according to this=20
>explanation, seems that LISP or Scheme are enterprise too, except of=20
>"high-phrases" AKA "...our very educated managers...", "...our high=20
>business...", "...our success in the market..." and so on.
.
.
While you probably recognized the humor in timbot's
reply, it's hard to appreciate from the outside its
analytic perfection. His definition PRECISELY cap-
tures the arrogance and anti-intellectualism that
"enterprise" generally bears.
Laura Creighton
<snip>
>
> Learning Python is straight forward, and doesn't scare of a COBOL
> programmer in the way that C++ or Java would.
>
Is getting a float when they wanted a fixed-decimal a problem?
Laura Creighton
Cameron Laird
It definitely is for many, I can report, and you're quite
right to ask.
C++, Java, and Python can all define BCD classes, of course.
I'd rather not start now with a comparison of how their
respective overloading syntaxes make Cobolists (un)comfortable.
James J. Besemer
Cameron Laird wrote:
> While you probably recognized the humor in timbot's
> reply, it's hard to appreciate from the outside its
> analytic perfection. His definition PRECISELY cap-
> tures the arrogance and anti-intellectualism that
> "enterprise" generally bears.
Correct. Many enterprise apps only handle peoples' money
whereas most consumer, research and educational apps
process vastly more valuable data.
--jb
--
James J. Besemer 503-280-0838 voice
http://cascade-sys.com 503-280-0375 fax
mailto:j...@cascade-sys.com
Cliff Wells
Tim Peters wrote:
> [builder]
> > Python has many fans in the open source community, but is it ready for
> > the enterprise?
>
> [Bo M. Maryniuck]
> > What the buzzword "the enterprise" is (as other buzzwords, aka
> > XML, Java etc)?
>
> It's an especially annoying American buzzword for "business use, as opposed
> to consumer, research, or educational use". Your enterprise-ready software
> is primed to take on the challenge of synergizing mission-critical business
> logic in empowering ways. IOW, it computes the sales tax right more often
> than not <wink>.
>
> to-the-next-level-going-forward-ly y'rs - tim
I always took "enterprise" to mean "runs on an AS/400 with a text interface",
or possibly as a synonym for "token-ring".
--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308 (800) 735-0555 x308
Martijn Faassen
> On Thu, 11 Jul 2002 05:47:22 -0400
> Tim Peters wrote:
>> It's an especially annoying American buzzword for "business use, as opposed
>> to consumer, research, or educational use". Your enterprise-ready software
>> is primed to take on the challenge of synergizing mission-critical business
>> logic in empowering ways. IOW, it computes the sales tax right more often
>> than not <wink>.
>>
> I always took "enterprise" to mean "runs on an AS/400 with a text interface",
> or possibly as a synonym for "token-ring".
I thought it involved that starship with the federation and the vulcans and
such. Their computer system gets taken over by alien entities quite
frequently, so I imagine they run software for the Enterprise.
Deflect-the-warp-tetrion-plasma-field-dimensional-flux-ly yours,
Aahz
Max Ischenko <m...@malva.com.uaREMOVE.IT> wrote:
> builder wrote:
>>
>> Python has many fans in the open source community, but is it ready for
>> the enterprise? Here are the advantages and disadvantages of using
>> Python in the corporate environment.
>> http://builder.com.com/article.jhtml?id=u00420020709DGS01.htm
>
>After reading their ah...well...stupid
>article about XP, I won't even bother to look at this.
It's written by Dan Shafer, who actually knows something about Python;
builder.com is only the publisher.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
Project Vote Smart: http://www.vote-smart.org/
Cliff Wells
Martijn Faassen wrote:
> Cliff Wells <logiplex...@earthlink.net> wrote:
> > On Thu, 11 Jul 2002 05:47:22 -0400
> > Tim Peters wrote:
> [the enterprise]
> >> It's an especially annoying American buzzword for "business use, as
> >opposed> to consumer, research, or educational use". Your enterprise-ready
> >software> is primed to take on the challenge of synergizing mission-critical
> >business> logic in empowering ways. IOW, it computes the sales tax right
> >more often> than not <wink>.
> >>
>
> > I always took "enterprise" to mean "runs on an AS/400 with a text
> > interface", or possibly as a synonym for "token-ring".
>
> I thought it involved that starship with the federation and the vulcans and
> such. Their computer system gets taken over by alien entities quite
> frequently, so I imagine they run software for the Enterprise.
Haven't those fools on the Enterprise installed all of the service packs???
SP5 for Windows SD45245 will have been available for some time by then.
Kim Petersen
It seems that Cameron already answered this one ;-)
But i should say that this hasn't become a problem here yet, as the
programmers know that there will be sacrifices on both ends of this
conversion (Cobol -> Python). I have a feeling that i will be forced to
write a some kind of framework for the programmers, to encompass some of
the output formatting types in Cobol and possibly also a transparent
class to do fixed decimal...
But we haven't reached that stage yet, first things first ;-) And in
this case it was extending the Cobol runtime with the ability to call
python programs and functions dynamically (we're using RM-Cobol-85 7.1)
- this is firmly established at this point - and i'm considering
releasing this to the wider community as open-source (i'm for it - but
i'm not sure about my Boss ;-)) - Unfortunatly the extension cannot do
the reverse (eg. performing cobol paragraphs (functions)) because of the
way the language is setup. But type conversion between Cobol and Python
is (almost) transparent (unfortunatly it cannot be 100% transparent, as
Cobol calls subprograms with arguments by reference).
>
> Laura Creighton
>
>
