Groups > comp.lang.python > #65698 > unrolled thread

What are the kinds of software that are not advisable to be developed using Python?

Started by	Sam <lightaiyee@gmail.com>
First post	2014-02-08 15:54 -0800
Last post	2014-02-12 01:37 +1100
Articles	3 on this page of 23 — 16 participants

Back to article view | Back to comp.lang.python

Page 2 of 2 — ← Prev page 1 [2]

#65889

From	Tim Daneliuk <tundra@tundraware.com>
Date	2014-02-10 23:50 -0600
Message-ID	<52F9BA09.5060303@tundraware.com>
In reply to	#65885

On 02/10/2014 11:35 PM, Steven D'Aprano wrote:
> On Mon, 10 Feb 2014 22:40:48 -0600, Tim Daneliuk wrote:
>
>> On 02/08/2014 05:54 PM, Sam wrote:
>>> I got to know about Python a few months ago and today, I want to
>>> develop only using Python because of its code readability. This is not
>>> a healthy bias. To play my own devil's advocate, I have a question.
>>> What are the kinds of software that are not advisable to be developed
>>> using Python?
>
> [snip a bunch of good examples]
>
>> Applications in which you do not want the casual reader to be able to
>> derive the meaning of the source code.
>
> That's a bad example. Do you think that the casual reader will be able to
> understand the meaning of .pyc files?
>
>


Point taken :)

-- 
----------------------------------------------------------------------------
Tim Daneliuk     tundra@tundraware.com
PGP Key:         http://www.tundraware.com/PGP/

[toc] | [prev] | [next] | [standalone]

#65908

From	Roy Smith <roy@panix.com>
Date	2014-02-11 09:24 -0500
Message-ID	<roy-ACA117.09240511022014@news.panix.com>
In reply to	#65885

In article <52f9b6af$0$11128$c3e8da3@news.astraweb.com>,
 Steven D'Aprano <steve@pearwood.info> wrote:

> On Mon, 10 Feb 2014 22:40:48 -0600, Tim Daneliuk wrote:
> 
> > On 02/08/2014 05:54 PM, Sam wrote:
> >> I got to know about Python a few months ago and today, I want to
> >> develop only using Python because of its code readability. This is not
> >> a healthy bias. To play my own devil's advocate, I have a question.
> >> What are the kinds of software that are not advisable to be developed
> >> using Python?
> 
> [snip a bunch of good examples]
> 
> > Applications in which you do not want the casual reader to be able to
> > derive the meaning of the source code.
> 
> That's a bad example. Do you think that the casual reader will be able to 
> understand the meaning of .pyc files?

No, but anybody with script-kiddie level sophistication can download a 
pyc decompiler and get back a pretty good representation of what the 
source was.

Whether I mind shipping my source, or you mind shipping your source 
isn't really what matters here.  What matters is that there *are* 
people/companies who don't want to expose their source.  Perhaps for 
reasons we don't agree with.  For those people, Python is not a good 
choice.

[toc] | [prev] | [next] | [standalone]

#65911

From	Chris Angelico <rosuav@gmail.com>
Date	2014-02-12 01:37 +1100
Message-ID	<mailman.6671.1392129460.18130.python-list@python.org>
In reply to	#65908

On Wed, Feb 12, 2014 at 1:24 AM, Roy Smith <roy@panix.com> wrote:
> Whether I mind shipping my source, or you mind shipping your source
> isn't really what matters here.  What matters is that there *are*
> people/companies who don't want to expose their source.  Perhaps for
> reasons we don't agree with.  For those people, Python is not a good
> choice.

But if it comes to that, there's really nothing that's all that great
a choice. After all, a small amount of introspection will identify the
external references in something (even C code has that, unless every
single call is statically linked; and even then, I've used gdb
usefully on other people's optimized binaries), so while someone might
not be able to figure out how your code works, they can at least
figure out what it's doing, and call on it directly. The only
difference between a .pyc file and a binary executable is that the pyc
bytecode is written for a virtual machine rather than a physical CPU.

It's not a matter of "this is good, that is bad", but a spectrum of
difficulties - optimized C code with everything statically linked is
about as close to one extreme as you'll get without consciously
obfuscating your code, and well-commented source is the opposite
extreme. A minified source file, a .pyc file, or a dynamically linked
.so, all are just someplace along that range. It's just a question of
how much time and effort it takes to figure out the internals of the
code.

Considering that there are big companies spending lots of money
devising DRM schemes, and their code often gets decompiled or reverse
engineered within a day of release, I'd have to say that even
obfuscated code is no real barrier. The *only* way to expose nothing
is to publish nothing - which, these days, usually means running your
software on a server and distributing a fairly dumb client... a model
that MUDs have been using to great effect for decades, and are even
today able to be run commercially.

ChrisA

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

csiph-web

What are the kinds of software that are not advisable to be developed using Python?

Contents

#65889

#65908

#65911