where are the program that are written in python?
Deep_Feelings
last .... 15+ years or so ? right ?
however by having a look at this page http://wiki.python.org/moin/Applications
i could not see many programs written in python (i will be interested
more in COMMERCIAL programs written in python ). and to be honest ,i
tried some of the programs in that list and all the programs that i
tried either dead projects or so buggy !
1- where are the programs that is written in python ?
2- python is high productivity language : why there are no commercial
programs written in python ?
is python a valid practical programming language ?
why it is not used in commercial software ?
please don't mention programs where python was used as a glue ,those
programs are not actually written in python.
any help will be appreciated
thank you
Simon Brunning
> 1- where are the programs that is written in python ?
> 2- python is high productivity language : why there are no commercial
> programs written in python ?
See http://www.python.org/about/success/
--
Cheers,
Simon B.
Martin P. Hellwig
> python is not a new programming language ,it has been there for the
> last .... 15+ years or so ? right ?
>
> however by having a look at this page http://wiki.python.org/moin/Applications
> i could not see many programs written in python (i will be interested
> more in COMMERCIAL programs written in python ). and to be honest ,i
> tried some of the programs in that list and all the programs that i
> tried either dead projects or so buggy !
actually have never looked at it.
>
> 1- where are the programs that is written in python ?
> 2- python is high productivity language : why there are no commercial
> programs written in python ?
>
> is python a valid practical programming language ?
> why it is not used in commercial software ?
languages. For example, the average user knows mac and windows, the
average admin knows there is also something like linux, and the average
linux admin knows there is also something like BSD.
>
> please don't mention programs where python was used as a glue ,those
> programs are not actually written in python.
software needs a lot of buzzwords to shift any market interest.
I have participated in a couple of 'pure' Python programs, used by
Airbus, Randstad and a whole fleet of small firms. But yes, off the
shelve software seems to be either written in Java or any .net equivalent.
>
> any help will be appreciated
>
> thank you
hth
--
mph
Deep_Feelings
> On 21 May 2010 11:21:11 UTC+1, Deep_Feelings <doctore...@gmail.com> wrote:
>
> Seehttp://www.python.org/about/success/
thankx for reply.
from that list i have a feeling that python is acting only as "quick
and dirty work" nothing more !
News123
Simon Brunning
> from that list i have a feeling that python is acting only as "quick
> and dirty work" nothing more !
Really?
Well, in any case, I can tell you that I know of a number of large
commercial web sites built with Django. I just can't tell you what
they are. ;-)
--
Cheers,
Simon B.
Wolfgang Rohdewald
> > I don't know of any big game written in python. ( meaning
> > python code, using c++ libs
would you call 8702 python statements big? If so,
Kajongg would be a candidate.
--
Wolfgang
Adam Tauno Williams
> On 05/21/10 11:21, Deep_Feelings wrote:
> > however by having a look at this page http://wiki.python.org/moin/Applications
> > i could not see many programs written in python (i will be interested
> > more in COMMERCIAL programs written in python ). and to be honest ,i
> > tried some of the programs in that list and all the programs that i
> > tried either dead projects or so buggy !
Most projects are dead projects; that is just the natural state of
things regardless of language. Just browse Sourceforge for awhile.
> It's a wiki, if anybody is interested they could change the page, I
> actually have never looked at it.
I've looked it over, there is some interesting stuff. But why
contribute a story when you could be coding on your project! A
perennial problem. :)
> > 1- where are the programs that is written in python ?
> > 2- python is high productivity language : why there are no commercial
> > programs written in python ?
> > is python a valid practical programming language ?
> > why it is not used in commercial software ?
I suppose it depends on your use of the term "used". It is used a *lot*
in the SOA / Workflow world - in the form of Jython. That provides a
very nice way to extend Java applications [it is still Python! Python
is a language, not a runtime].
In general to 'core' of large applications are, IMO, easier to maintain
in the more rigid statically typed languages as the toolchain can do
more work for you. Of course someone here will have a fit about that
statement.
> > please don't mention programs where python was used as a glue
Why not?
And what about Gwibber? Zeitgeist? BitTorrent? Zope/Plone? Those are
all certainly "real" applications. Zope is almost an industry unto
itself.
> ,those programs are not actually written in python.
I think your distinction is not valid. "glue" is a vital part of every
enterprise. And the sophistication of some "glue" certainly surpasses
many "applications".
> Python is used in a lot in custom applications, while off the shelve
> software needs a lot of buzzwords to shift any market interest.
> I have participated in a couple of 'pure' Python programs, used by
> Airbus, Randstad and a whole fleet of small firms. But yes, off the
> shelve software seems to be either written in Java or any .net equivalent.
<http://hackerboss.com/how-to-distribute-commercial-python-applications/> is an interesting read. Certainly the 'packaging' mechanism is less end-user friendly than .NET. I personally would not choose to create an end-user application in Python; but it has become my first choice for server-side development.
--
Adam Tauno Williams <awil...@whitemice.org> LPIC-1, Novell CLA
<http://www.whitemiceconsulting.com>
OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba
Jason Scheirer
> python is not a new programming language ,it has been there for the
> last .... 15+ years or so ? right ?
>
> i could not see many programs written in python (i will be interested
> more in COMMERCIAL programs written in python ). and to be honest ,i
> tried some of the programs in that list and all the programs that i
> tried either dead projects or so buggy !
>
> 1- where are the programs that is written in python ?
> 2- python is high productivity language : why there are no commercial
> programs written in python ?
>
> is python a valid practical programming language ?
> why it is not used in commercial software ?
>
> please don't mention programs where python was used as a glue ,those
> programs are not actually written in python.
>
> any help will be appreciated
>
> thank you
I write commercial software full-time in Python (well, mixed with C++)
at ESRI. I have been able to make a living developing in Python full
time at various places for the last 4 years. I can assure you that
there is plenty of commercial software out there that uses Python. The
reason you don't *see* it is because the development language for a
commercial product is a lot less important than the functionality of
the product, so "WRITTEN IN PYTHON!!!!" is likely not going to be a
bullet point on a marketing slide. And quite frankly, it should be a
trade secret for the companies enlightened enough to use it as their
language of choice because it is to productive that it provides a
competitive advantage.
Terry Reedy
Try 'quick and clean' and you would be more accurate.
But that would not be so trollish, would it?
tjr
Patrick Maupin
> i could not see many programs written in python
Well you could try PyPi, or even a search on googlecode.
> (i will be interested
> more in COMMERCIAL programs written in python ).
What do you mean by commercial, and why?
> and to be honest ,i
> tried some of the programs in that list and all the programs that i
> tried either dead projects or so buggy !
So, you want us to believe that you desperately want to pay someone
for working Python software, but are finding it hard to find some?
> 1- where are the programs that is written in python ?
All over the place.
> 2- python is high productivity language : why there are no commercial
> programs written in python ?
There are a lot of commercial programs written in Python. But any
company which thinks it has a lock on some kind of super secret sauce
isn't going to use Python, because it's very easy to reverse engineer
even compiled Python programs. Also, any company in a competitive
market where execution speed is extremely important might choose some
other language because, frankly, the fact that a development tool is
highly productive is not something that the end user directly cares
about. (But the up-front choice of another language simply for speed,
rather than prototyping with Python and then recoding the slow bits,
would probably be a decision borne of ignorance.)
> is python a valid practical programming language ?
Absolutely. I've been using it heavily for 11 years, for real work,
for which I get paid.
> why it is not used in commercial software ?
What makes you think that it's not? Is this some kind of "big lie"
strategy? To what end?
> any help will be appreciated
It's hard to help when you don't describe the problem. Reading
between the lines, the most charitable and probable interpretation of
your problem I can come up with is that you think you're going to
create a multi-billion dollar computer program and you're desperately
trying to validate your preconceived notion that Python isn't the
language to write it in. Sorry, but I can't help with that.
Regards,
Pat
geremy condra
Yeah, there's not really a lot of industry support. If only we could
get a huge search engine like bing to use python extensively we'd
be in a lot better shape.
Geremy Condra
Terry Reedy
> python is not a new programming language ,it has been there for the
> last .... 15+ years or so ? right ?
>
> however by having a look at this page http://wiki.python.org/moin/Applications
> i could not see many programs written in python (i will be interested
> more in COMMERCIAL programs written in python ). and to be honest ,i
There are two kinds of 'commercial' programs.
1. The vast majority are proprietary programs kept within a company for
its own use. As long as these work as intended, they are mostly
invisible to the outside world.
2. Programs sold to anyone who wants them.
Python trades programmer speed for execution speed. If a successful
Python program is going to be run millions of times, it makes economic
sense to convert time-hogging parts to (for instance) C. In fact, this
is a consideration in deciding what functions should be builtin and
which stdlib modules are written or rewritten in C.
Programs being sold tend to be compared to competitors on speed with
perhaps more weight than they rationally should. Speed is easier to
measure than, for instance, lack of bugs.
Python programs can be and sometimes are distributed as .exe files. The
users of such neither know nor care that some of the source is Python.
> tried some of the programs in that list and all the programs that i
> tried either dead projects or so buggy !
>
> 1- where are the programs that is written in python ?
Mostly kept private. For instance, GvR, Python's inventor, spent part of
his first year at Google writing a neat-looking programmer console
program in Python (Mondrian) designed to improve the productivity of
Google programmers. As far as I know, Google has not released it.
> please don't mention programs where python was used as a glue ,those
> programs are not actually written in python.
A C program glues together micro-coded functions. Even a 'pure' CPython
program glues together C-coded functions. Some are in builtins, some are
imported from the stdlib, and some can be imported from 3rd party
packages. The extensibility of CPython is part of its design.
Terry Jan Reedy
Tim Chase
>>> See http://www.python.org/about/success/
>>
>> thankx for reply.
>>
>> from that list i have a feeling that python is acting only as "quick
>> and dirty work" nothing more !
>
> get a huge search engine like bing to use python extensively we'd
> be in a lot better shape.
Or if an organization known to hire a bunch of rocket-scientists
were to use Python...that would make it a real language...
-tkc
Aahz
Patrick Maupin <pma...@gmail.com> wrote:
>
>There are a lot of commercial programs written in Python. But any
>company which thinks it has a lock on some kind of super secret sauce
>isn't going to use Python, because it's very easy to reverse engineer
>even compiled Python programs.
That's not always true. Both my employer (Egnyte) and one of our main
competitors (Dropbox) use Python in our clients. We don't care much
because using our servers is a requirement of the client.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
f u cn rd ths, u cn gt a gd jb n nx prgrmmng.
Ben Finney
> In article <eb0c9aec-428f-45a2...@z17g2000vbd.googlegroups.com>,
> Patrick Maupin <pma...@gmail.com> wrote:
> >
> >There are a lot of commercial programs written in Python. But any
> >company which thinks it has a lock on some kind of super secret sauce
> >isn't going to use Python, because it's very easy to reverse engineer
> >even compiled Python programs.
>
> That's not always true. Both my employer (Egnyte) and one of our main
> competitors (Dropbox) use Python in our clients. We don't care much
> because using our servers is a requirement of the client.
Doesn't that mean those companies don't fit the above description? That
is, neither of them “thinks it has a lock on some kind of super secret
sauce” in the programs. So they don't seem to be counter-examples.
--
\ “The right to search for truth implies also a duty; one must |
`\ not conceal any part of what one has recognized to be true.” |
_o__) —Albert Einstein |
Ben Finney
Lie Ryan
> On 5/21/2010 6:21 AM, Deep_Feelings wrote:
>> python is not a new programming language ,it has been there for the
>> last .... 15+ years or so ? right ?
>>
>> however by having a look at this page
>> http://wiki.python.org/moin/Applications
>> i could not see many programs written in python (i will be interested
>> more in COMMERCIAL programs written in python ). and to be honest ,i
>
> There are two kinds of 'commercial' programs.
> 1. The vast majority are proprietary programs kept within a company for
> its own use. As long as these work as intended, they are mostly
> invisible to the outside world.
> 2. Programs sold to anyone who wants them.
>
> Python trades programmer speed for execution speed. If a successful
> Python program is going to be run millions of times, it makes economic
> sense to convert time-hogging parts to (for instance) C. In fact, this
> is a consideration in deciding what functions should be builtin and
> which stdlib modules are written or rewritten in C.
>
> Programs being sold tend to be compared to competitors on speed with
> perhaps more weight than they rationally should. Speed is easier to
> measure than, for instance, lack of bugs.
doubting python's speed? Look at Mercurial vs. SVN; Mercurial is written
in Python while SVN in C. Mercurial beats SVN in speed by several orders
of magnitude.
One of Mercurial's design goal was to be faster than SVN, if the
programmers have naively believed that choice of language would matter
to program's speed, they'd choose to write Mercurial in assembly instead
(the same argument applies to Git, written in shell scripts).
Now, you may think this is an unfair comparison, since Mercurial is hype
and new, SVN is antiquated and old. But it shows that in real-life, the
language being inherently slow often dosn't matter. What matters more
are the choice of data structure and algorithm, I/O speed, network
latency, and development speed.
Chris Rebert
Erm, in fairness, I recall hearing that some speed-critical bits of hg
are written in C. It does lend credence to the "Python as glue
language" argument though; I doubt hg's extensibility and friendly
interface would have been as easy to implement it C (particularly the
slick instant-server feature).
Cheers,
Chris
--
http://blog.rebertia.com
Carl Banks
> please don't mention programs where python was used as a glue ,those
> programs are not actually written in python.
I hate to answer a troll, but I'll just mention that when people talk
about a "glue language", they're not talking about using some Python
code to connect two big systems together (although Python is good for
that).
What they are saying is that Python is a good language to serve as
high-level logic interfacing lots of different library codes--often
but not always written in faster languages--together in one program.
In that case, yes, the program is written in Python.
The word "glue" is probably not the best metaphor, since to most
people it means "something you use to connect two objects together".
A better metaphor would be like a "substrate language".
A lot of materials do use a form of glue as the substrate, but never
mind that.
Carl Banks
sturlamolden
> 1- where are the programs that is written in python ?
You could search for them with Google and download your results
Bittorrent.
> is python a valid practical programming language ?
No, it is probably Turing incomplete.
Patrick Maupin
> In article <eb0c9aec-428f-45a2-a985-5b33906e0...@z17g2000vbd.googlegroups.com>,
> Patrick Maupin <pmau...@gmail.com> wrote:
> >There are a lot of commercial programs written in Python. But any
> >company which thinks it has a lock on some kind of super secret sauce
> >isn't going to use Python, because it's very easy to reverse engineer
> >even compiled Python programs.
>
> That's not always true. Both my employer (Egnyte) and one of our main
> competitors (Dropbox) use Python in our clients. We don't care much
> because using our servers is a requirement of the client.
Absolutely. I wrote my post after the OP's second post, and from that
short, derisive tome, I inferred that the OP's definition of
"commercial" was quite narrow, so I was trying to respond on the basis
of what he would consider "commercial," which BTW, probably wouldn't
include a lot of programs that, e.g. Google uses to make money.
Regards,
Pat
Patrick Maupin
> a...@pythoncraft.com (Aahz) writes:
> > In article <eb0c9aec-428f-45a2-a985-5b33906e0...@z17g2000vbd.googlegroups.com>,
>
> > >There are a lot of commercial programs written in Python. But any
> > >company which thinks it has a lock on some kind of super secret sauce
> > >isn't going to use Python, because it's very easy to reverse engineer
> > >even compiled Python programs.
>
> > That's not always true. Both my employer (Egnyte) and one of our main
> > competitors (Dropbox) use Python in our clients. We don't care much
> > because using our servers is a requirement of the client.
>
> Doesn't that mean those companies don't fit the above description? That
> is, neither of them “thinks it has a lock on some kind of super secret
> sauce” in the programs. So they don't seem to be counter-examples.
Just because someone has competition doesn't mean they don't think
they have secret sauce. I think Aahz's main point was that in his sub-
industry, the secret sauce is guarded by not actually letting the
customer have access to executable code, other than through the
network.
Regards,
Pat
sturlamolden
> There are a lot of commercial programs written in Python. But any
> company which thinks it has a lock on some kind of super secret sauce
> isn't going to use Python, because it's very easy to reverse engineer
> even compiled Python programs.
Decompiling Java or .NET bytecode isn't rocket science either.
> Also, any company in a competitive
> market where execution speed is extremely important might choose some
> other language because, frankly, the fact that a development tool is
> highly productive is not something that the end user directly cares
> about.
That only applies to CPU bound program code (most program code is I/O
bound), and only to computational bottlenecks (usually less than 5% of
the code) in the CPU bound programs. Today, most programs are I/O
bound: You don't get a faster network connection or harddrive by using
C. In this case, performance depends on other factors than choice of
language. That is why Mercurial (written in Python) can be much faster
than SVN (written in C).
For computational bottlenecks we might want to try high-performance
numerical libraries first. If that does not help, we can try to
replace some Python with C. Python as "glue" does not mean Python is
inferior to C. It just means it is a PITA to write C or Fortran all
the time. I value my own time a lot more than a few extra CPU cycles.
Who cares about speed where it is not needed?
There are also a lot of uneducated FUD about the GIL: First, for I/O
bound programs the GIL is not an issue, as threads that are blocked
and waiting for I/O do not compete for the GIL. (That should be rather
obvious, but my guesstimate is that most programmers do not understand
this.) Second, for CPU bound programs the GIL is not an issue either:
Fine-grained parallelization is done elsewhere than Python, e.g.
hidden inside numerical libraries or implemented with OpenMP pragmas
in C code. Course-grained parallelization can be done in Python using
Python threads, as the GIL can be released in C using a couple of
macros (or using ctypes.CDLL). In practice, the GIL rarely impairs
anything, but create a lot of FUD form persons who do not understand
the problem.
Deep_Feelings
hope you best luck in your life
Tim Chase
> That only applies to CPU bound program code (most program code is I/O
> bound), and only to computational bottlenecks (usually less than 5% of
> the code) in the CPU bound programs. Today, most programs are I/O
> bound: You don't get a faster network connection or harddrive by using
> C. In this case, performance depends on other factors than choice of
> language. That is why Mercurial (written in Python) can be much faster
> than SVN (written in C).
>
> For computational bottlenecks we might want to try high-performance
> numerical libraries first. If that does not help, we can try to
> replace some Python with C.
Just as an aside, last I checked, mercurial had some core code in
C for speed. But that doesn't negate your line of reasoning,
rather it cements it -- they found it was most productive to work
in Python, but needed the core bits to improve in speed so
rewrote them in C.
I'd also include that a change in algorithm can be a big help for
speeding up CPU-bound code. It doesn't matter much if you're
using Python or hand-coding that inner loop in C/ASM, if you're
using a O(2^N) algorithm. I find it easier to write good/speedy
algorithms in Python because I have a toolkit of built-in
data-types (sets, dicts, lists, etc) that I can reach for,
without making sure I've added-on certain C libraries.
-tkc
Aahz
Tim Chase <pytho...@tim.thechases.com> wrote:
>
>I'd also include that a change in algorithm can be a big help for
>speeding up CPU-bound code. It doesn't matter much if you're using
>Python or hand-coding that inner loop in C/ASM, if you're using a
>O(2^N) algorithm.
Rewriting an algorithm also helps I/O-bound code when you're doing
something stupid like querying a DB multiple times for each record
instead of caching the result. Also, rewriting your algorithm to just
pull the entire DB into RAM helps, too. (If you know your dataset must
fit into RAM, anyway, in order to process your algorithm.)
sturlamolden
> Rewriting an algorithm also helps I/O-bound code
Yes it does, if it involves how we do I/O. Algorithms are just as
important for I/O bound as they are for compute bound code.
But implementing an algorithm in C as opposed to Python would not
improve nearly as much for I/O bound as it could do for compute bound
code.
Patrick Maupin
> On 21 Mai, 20:20, Patrick Maupin <pmau...@gmail.com> wrote:
> > Also, any company in a competitive
> > market where execution speed is extremely important might choose some
> > other language because, frankly, the fact that a development tool is
> > highly productive is not something that the end user directly cares
> > about.
>
> That only applies to CPU bound program code (most program code is I/O
> bound), and only to computational bottlenecks (usually less than 5% of
> the code) in the CPU bound programs. Today, most programs are I/O
> bound: You don't get a faster network connection or harddrive by using
> C. In this case, performance depends on other factors than choice of
> language. That is why Mercurial (written in Python) can be much faster
> than SVN (written in C).
>
> For computational bottlenecks we might want to try high-performance
> numerical libraries first. If that does not help, we can try to
> replace some Python with C. Python as "glue" does not mean Python is
> inferior to C. It just means it is a PITA to write C or Fortran all
> the time. I value my own time a lot more than a few extra CPU cycles.
> Who cares about speed where it is not needed?
I think we're in violent agreement here -- you neglected to quote the
part where I said "(But the up-front choice of another language simply
for speed, rather than prototyping with Python and then recoding the
slow bits, would probably be a decision borne of ignorance.)"
Regards,
Pat
Terry Reedy
> On 05/22/10 04:47, Terry Reedy wrote:
>> On 5/21/2010 6:21 AM, Deep_Feelings wrote:
>>> python is not a new programming language ,it has been there for the
>>> last .... 15+ years or so ? right ?
>>>
>>> however by having a look at this page
>>> http://wiki.python.org/moin/Applications
>>> i could not see many programs written in python (i will be interested
>>> more in COMMERCIAL programs written in python ). and to be honest ,i
>>
>> There are two kinds of 'commercial' programs.
>> 1. The vast majority are proprietary programs kept within a company for
>> its own use. As long as these work as intended, they are mostly
>> invisible to the outside world.
>> 2. Programs sold to anyone who wants them.
>>
>> Python trades programmer speed for execution speed. If a successful
>> Python program is going to be run millions of times, it makes economic
>> sense to convert time-hogging parts to (for instance) C. In fact, this
>> is a consideration in deciding what functions should be builtin and
>> which stdlib modules are written or rewritten in C.
>>
>> Programs being sold tend to be compared to competitors on speed with
>> perhaps more weight than they rationally should. Speed is easier to
>> measure than, for instance, lack of bugs.
>
> doubting python's speed?
The is a somewhat bizarre response to me. I have been promoting Python
for about 13 years, since I dubbed it 'executable pseudocode', which is
to say, easy to write, read, understand, and improve. I am also a
realist. Any fixed (C)Python program can be sped up, at least a bit, and
possibly more, by recoding in C. At minimum, the bytecodes can be
replaced by the C code and C-API calls that they get normally get
translated into. Ints can be unboxed. Etcetera. This tend to freeze a
program, which is fine when development is finished.
I believe Raymond wrote each itertool (or at least most) in Python
first, then rewrote each in C for speed, since they are intented to be
repeatedly used components of other Python programs. He is not 'doubting
Python's speed', just being realistic.
> Look at Mercurial vs. SVN;
Neither are being sold, as far as I know.
> Mercurial is written in Python while SVN in C.
> Mercurial beats SVN in speed by several orders
> of magnitude.
Because, as I said, and as you explain further, Python favors programmer
speed, including speed of testing new algorithms, over raw execution
speed of current algorithms. (Current) speed is (also) easier to test
than improvability and hence possible speed improvements.
>
> One of Mercurial's design goal was to be faster than SVN, if the
> programmers have naively believed that choice of language would matter
> to program's speed, they'd choose to write Mercurial in assembly instead
> (the same argument applies to Git, written in shell scripts).
>
> Now, you may think this is an unfair comparison, since Mercurial is hype
> and new, SVN is antiquated and old. But it shows that in real-life, the
> language being inherently slow often dosn't matter. What matters more
> are the choice of data structure and algorithm, I/O speed, network
> latency, and development speed.
If and when mercurial deveopment slows down, some of its developers
might consider whether any of the utility functions written in Python
might usefully be rewritten in C. One of the intentional virtues of
Python is that one can transparently convert part or all of a module
*without changing* the import and use of the module.
Terry Jan Reedy
Patrick Maupin
> Because, as I said, and as you explain further, Python favors programmer
> speed, including speed of testing new algorithms, over raw execution
> speed of current algorithms. (Current) speed is (also) easier to test
> than improvability and hence possible speed improvements.
First of all, I don't think you and Lie have any basic disagreements.
The key realization is that the quantitative difference in programmer
speed you mention is so large (orders of magnitude) that, for many
classes of problems, it is not just *possible*, but actually
*probable*, that a Python implementation *will be faster* than a C
implementation. Yes, you are absolutely correct that most Python
programs can be made faster by adding a bit of C, but that doesn't
negate the fact that if I can throw 'x' man-hours at a problem, for
lots of real-world values of 'x' and of 'the problem', a pure Python
implementation will run rings around a pure C implementation, assuming
the C implementation even works by the time I've burned through 'x'
hours. I discussed this a bit on this newsgroup over five years ago,
and the points are still pertinent:
http://groups.google.com/group/comp.lang.python/msg/910a54ddec946567
> If and when mercurial deveopment slows down, some of its developers
> might consider whether any of the utility functions written in Python
> might usefully be rewritten in C. One of the intentional virtues of
> Python is that one can transparently convert part or all of a module
> *without changing* the import and use of the module.
I don't even think that Mercurial development has to slow down to
decide to recode a few things in C. A tiny bit of C at the right
place can often provide more than enough leverage to be worthwhile,
and be small enough to throw away if need be.
Regards,
Pat
Patrick Maupin
> Erm, in fairness, I recall hearing that some speed-critical bits of hg
> are written in C. It does lend credence to the "Python as glue
> language" argument though; I doubt hg's extensibility and friendly
> interface would have been as easy to implement it C (particularly the
> slick instant-server feature).
Is C viewed as a "glue language" in those environments where it is the
primary tool and sometimes some small bits are recoded into assembly
language for speed?
Regards,
Pat
Adam Tauno Williams
> On May 21, 5:21 am, Deep_Feelings <doctore...@gmail.com> wrote:
> > 2- python is high productivity language : why there are no commercial
> > programs written in python ?
> There are a lot of commercial programs written in Python. But any
> company which thinks it has a lock on some kind of super secret sauce
> isn't going to use Python,
Is it [only] the aspect of being "sold" that makes software
"commercial"?
A better question would be is how many Python applications, in house or
not, are used to facilitate commerce. Answer: a lot.
I have an Open Source project with >100,000 lines of Python code [which
I think qualifies as a 'real' application]
<https://www.ohloh.net/p/coils/analyses/latest>. But that it is Open
Source makes it non-commercial? I doubt anyone would use it outside of
a commercial environment, and one of its principle goals is to serve as
the backend for CRM systems [essentially commercial] and facilitate
automation of business processes [essentially commercial]. The 'secret
sauce' isn't the code [which is MIT licenses] but what you do with it.
But since the framework is essentially general purpose - why not publish
the code?
I think of my Open Source code as "commercial".
Gregory Ewing
> i will be interested more in COMMERCIAL programs written in python
I came across a game on Big Fish Games recently (it was
"The Moonstone" IIRC) that appeared to have been built using
Python and py2app.
--
Greg
sturlamolden
> I think we're in violent agreement here -- you neglected to quote the
> part where I said "(But the up-front choice of another language simply
> for speed, rather than prototyping with Python and then recoding the
> slow bits, would probably be a decision borne of ignorance.)"
I'm not arguing against you. You're argument is almost that which
Donald Knuth attributes to C.A.R. Hoare: "Premature optimization is
the root of all evil in computer programming." It's very true though.
sturlamolden
> Just as an aside, last I checked, mercurial had some core code in
> C for speed.
I've been writing scrintific software for over 10 years. I always find
myself writing small pieces of C now and then. It is usally because
header files are too complicated to expose to Python. I will e.g. make
OpenGL calls from C, and then call the rendering routine from Python
with ctypes. It saves me the work of exposing OpenGL (or whatever) to
Python. There are already header files that make the API available to
C.
Yes I know about PyOpenGL, but then there is the speed argument: From
C I can make epeated calls to functions like glVertex4f with minial
loss of efficacy. Calling glVertex4f from Python (e.g. PyOpenGL) would
give me the Python (and possibly ctypes) overhead for each call, which
is considerable.
So there is the two arguments for using C now and then: (1) Save
programming time by not having to repeat header files and (2) make
programs run faster by avoiding the Python overhead. Some times it
matters, some times it don't. But it does not make sense to write C or
C++ all the time, nor does it help to use C or C++ for I/O bound
problems.
Lie Ryan
I'm not claiming Python is faster than C, but I'm just being a realists,
when I say that in real life 9 out of 10 writing a program in a slow
language doesn't really matter to actual program speed. I used Mercurial
as an example where the developers choose an initially irrational
decision of using a slow language (python) to beat the speed of a fast
language (C).
Of course, you can always point out the 1 case out of 10. In this cases,
python can still cope with C extension, Psyco, Numpy-and-friends,
Cython, or even dumping python and using full C all the way.
But the point still hold, that in real life, often the language's raw
speed doesn't really limit the program's speed.
David Cournapeau
> But the point still hold, that in real life, often the language's raw
> speed doesn't really limit the program's speed.
I would rather say that Python vs C does not matter until it does, and
it generally does when constants factor matter (which is one way to
draw the line between system programming and "general" programming).
It totally depends on the applications, I don't think you can draw
general arguments.
David
sturlamolden
> I would rather say that Python vs C does not matter until it does,
I disagree. C matters because it is portable assembly code. Which
means it is tedious and error prone to use, so avoiding it actually
matters. Hence C matters. Knowing when and when not to use C matters a
lot.
alex23
> I came across a game on Big Fish Games recently (it was
> "The Moonstone" IIRC) that appeared to have been built using
> Python and py2app.
Python tends to be used more for scripting internal game logic than
for every aspect of a game (which is, IMO, the right way to go about
it). It's not a huge list of commercial games that does this[1], but
it's a fairly classy one :)
1: http://en.wikipedia.org/wiki/Category:Python-scripted_video_games
Adam Tauno Williams
> Agree, reveres engineering is crucial issuer for programming
> language
> but every executable file can be cracked, for example by using
> disassembler!!!
> For each weapon there is antiweapon, so
> is it possible to prevent reveres engineering when customer have
> access to executable made from Python code???
No. But you can make it hard.
Store a GPG encrypted blob in your program that contains you secret
sauce, is decrypted to memory, executed, and then discarded. Setup
some kind of license manager like dongle or application to perform the
key management.
Terry Reedy
> is it possible to prevent reveres engineering when customer have access
> to executable made from Python code???
If there is, it is a trade secrets that you will not be able to reverse
engineer ;-).
Lie Ryan
> On Tue, 2010-05-25 at 18:49 +0500, Sandy Ydnas wrote:
>> Agree, reveres engineering is crucial issuer for programming
>> language
>> but every executable file can be cracked, for example by using
>> disassembler!!!
>> For each weapon there is antiweapon, so
>> is it possible to prevent reveres engineering when customer have
>> access to executable made from Python code???
>
> No. But you can make it hard.
>
> Store a GPG encrypted blob in your program that contains you secret
> sauce, is decrypted to memory, executed, and then discarded. Setup
> some kind of license manager like dongle or application to perform the
> key management.
That merely gives a false sense of security. If the program is decrypted
in memory, you can easily make a memory dump to get the unencrypted
program. If I am a competitor that can make economic advantage by
cracking your secret sauce, it wouldn't be difficult for me to do that.
D'Arcy J.M. Cain
Lie Ryan <lie....@gmail.com> wrote:
> That merely gives a false sense of security. If the program is decrypted
> in memory, you can easily make a memory dump to get the unencrypted
> program. If I am a competitor that can make economic advantage by
> cracking your secret sauce, it wouldn't be difficult for me to do that.
Yes, in fact the only people inconvenienced are your paying clients.
--
D'Arcy J.M. Cain <da...@druid.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
Grant Edwards
> On Wed, 26 May 2010 05:40:43 +1000
> Lie Ryan <lie....@gmail.com> wrote:
>
>> That merely gives a false sense of security. If the program is
>> decrypted in memory, you can easily make a memory dump to get the
>> unencrypted program. If I am a competitor that can make economic
>> advantage by cracking your secret sauce, it wouldn't be difficult for
>> me to do that.
>
> Yes, in fact the only people inconvenienced are your paying clients.
After several bad experiences over the years, I'm now willing go to
quite a bit of effort to avoid using products that require dongles,
node-locked licenses or license servers.
--
Grant Edwards grant.b.edwards Yow! Hold the MAYO & pass
at the COSMIC AWARENESS ...
gmail.com
Adam Tauno Williams
> On 05/26/10 01:09, Adam Tauno Williams wrote:
> > On Tue, 2010-05-25 at 18:49 +0500, Sandy Ydnas wrote:
> >> Agree, reveres engineering is crucial issuer for programming
> >> language
> >> but every executable file can be cracked, for example by using
> >> disassembler!!!
> >> For each weapon there is antiweapon, so
> >> is it possible to prevent reveres engineering when customer have
> >> access to executable made from Python code???
> > No. But you can make it hard.
> > Store a GPG encrypted blob in your program that contains you secret
> > sauce, is decrypted to memory, executed, and then discarded. Setup
> > some kind of license manager like dongle or application to perform the
> > key management.
> That merely gives a false sense of security.
There is no "true" sense of security. There is only degrees of
obfuscation, hence the first sentence: "No. But you can make it hard"
> If the program is decrypted
> in memory, you can easily make a memory dump
Easily? Really? You vastly over estimate the majority of computer
users. If someone who knows how to read the memory of a running process
wants your secret sauce - they are going to get it.
> to get the unencrypted
> program. If I am a competitor that can make economic advantage by
> cracking your secret sauce, it wouldn't be difficult for me to do that.
True. That is pretty much always true. The only effective solution is
to have your app call a web service [or some kind of RPC] to a server
where you keep the secret sauce hidden away.
Daniel Fetchinson
>> to executable made from Python code???
The only secure way of protecting your code is if you expose it as a
web service or some such. (Yes, people can still crack your web
server, but that's nitpicking :))
Cheers,
Daniel
--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
Ben Finney
+1 QOTW
--
\ “The best way to get information on Usenet is not to ask a |
`\ question, but to post the wrong information.” —Aahz |
_o__) |
Ben Finney