embed at geocities.com
Thu May 4 15:36:02 CEST 2000
I agree with all of Scotts ideas. I'd like Python to become just as flexible
and efficient a producer of Windows executables as Delphi is currently for
me. I think I'll always want and need Delphi around too. Different tools,
different jobs. Delphi is a non-starter as a system scripting tool, whereas
Python will always be great at that. I think Delphi will always be superior
as a means of distributing binary single executables (requiring no runtime,
vbrun.dll, .pyd files, or what have you).
However Python is coming along surprisingly well, for such a new Thing.
As for Python being a win for the customer, I think with PC performance at
current levels, and users requiring the ability to tailor their software,
Python is a great win for customers. I think the Windows philosophy of
"everything is supposed to be a 50 megabyte monolithic executable" is being
slowly pounded to death by the Internet and that Python and other tools with
a kind of Unix "do one thing well" heritage are going to continue to gather
steam on Windows. (Perl is another example.)
Python acceptance is up to programmers. customers pretty much take the best
product they can get. If python gains acceptance with Programmers, and
Programmers build a better mousetrap, the customers will be there.
Compare 2 contracts a company must choose between, Company A is writing in
Python and Company B is producing for you an Executable using VB enterprise:
1. cost to customer to keep a copy of Python around for future maintenance
by in house IT staff: $0
cost to customer to keep a copy of VB Enterprise around. ~$5K
2. Likelihood of aPython program being provided with Source is higher than
the likelihood of a
VB program being provided with source.
3. Portability of Python: Somewhat portable. VB is a non-starter on anything
More information about the Python-list