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

[Sam]

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 ofsoftware that are not advisable to be developed using Python?

 

[Denis McMahon]

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?

OS Kernels. Hardware drivers.

 

[Chris Angelico]

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?

Device drivers and operating systems. Definitely don't try writing
those in pure Python.

Anything that provides a C API is usually easier to program in C, so
you would want to write a Python-callable glue module. Sometimes
you'll find that there's nothing else to do but the module, in which
case you've pretty much written your app in C, but often you can write
a tiny driver script that calls on your functions - which means you
can, later on, write a GUI app that calls on the same functions. But
using ctypes for that is pretty messy and tedious. (Note that you
might be able to write your glue module using Cython. I've never done
this, but that's a sort of half-way mark between Python and C, with
most of the code feeling like Python but the facilities being like C.
Some day, I must try it.)

Projects that are already partly written in some other language, or
which should be written to use libraries in another language, usually
should be written in that language. Modifying your PHPBB forum should
probably be done in PHP, no matter what you think of that language
(and who doesn't).

Web applications that need to run on cheap web hosts usually need to
be written in PHP, too, but Python is available on a good few
"not-so-cheap" hosts, so that might not be a problem.

Heavy computation might be unideal in Python, but if you can grunge it
into NumPy operations, that won't be a problem.

For the rest, Python's probably a fine language. Applications,
servers, pretty much anything will work. Have at it!

ChrisA

 

[Roy Smith]

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?

If execution speed is the most important thing, Python would be the
wrong choice.

If you need to get very close to the hardware (such as when writing an
operating system), Python would be the wrong choice.

If you are writing software for an environment which has a
single-language ecosystem (i.e. iOS -> Objective C, or Android -> Java),
Python would be the wrong choice.

If, for security/business reasons, shipping only the executable, without
the end user having access to your original source, Python would be the
wrong language.

 

[Steven D'Aprano]

If execution speed is the most important thing, Python would be the
wrong choice.

PyPy can generate code which is comparable to compiled C in speed.
Perhaps you mean, "if execution speed is the most important thing, using
a naive Python interpreter may not be fast enough".

If you need to get very close to the hardware (such as when writing an
operating system), Python would be the wrong choice.

If you are writing software for an environment which has a
single-language ecosystem (i.e. iOS -> Objective C, or Android -> Java),
Python would be the wrong choice.
https://github.com/kivy/python-for-android
https://ep2013.europython.eu/conference/talks/developing-android-apps-completely-in-python
https://python-for-android.readthedocs.org/en/latest/
http://qpython.com/


If, for security/business reasons, shipping only the executable, without
the end user having access to your original source, Python would be the
wrong language.

Security by obscurity.

Nevertheless, although security by obscurity is ineffective[1], Python
supports it. You can ship only the .pyc files. For added obscurity, you
could put the .pyc files in a .zip file and ship that. For even more
obscurity, you could write a custom importer, and then ship your python
byte-code hidden in a mp3 or TIFF file.




[1] Shipping only compiled executables hasn't made Windows any more
secure, prevented viruses and malware from taking advantage of zero-day
exploits, or prevented software piracy.

 

[Michael Torrie]

Device drivers and operating systems. Definitely don't try writing
those in pure Python.

That all depends. Driving a USB device using libusb and Python might
just be the ticket to get things up and running quickly. At one time
someone wrote a Linux kernel module that allowed you to use Perl to
implement some kinds of driver things.

 

[Asaf Las]

Nevertheless, although security by obscurity is ineffective[1], Python
supports it. You can ship only the .pyc files. For added obscurity, you
could put the .pyc files in a .zip file and ship that. For even more
obscurity, you could write a custom importer, and then ship your python
byte-code hidden in a mp3 or TIFF file.

There are some code obfuscator for python but i never used them.

btw, Python could be language of choice for embedded systems if small footprint
vm could be developed. had seen similar for java having 10-20 KB byte sized
interpreter with very limited set of functions.

 

[Chris Angelico]

That all depends. Driving a USB device using libusb and Python might
just be the ticket to get things up and running quickly. At one time
someone wrote a Linux kernel module that allowed you to use Perl to
implement some kinds of driver things.

That's not the same; libusb is doing the low-level handling for you.
That's not the sense of "device driver" that gets really close to the
metal. I'm talking about real-time response to signals, I/O port and
interrupt handling, that kind of thing. The device driver will then
expose a higher-level API, maybe as a /dev/something openable, and
Python can control the device using that.

And that's something that Python *is* good at. I wouldn't use Python
to write a device driver for an RTL8169 card, but if I have that card
in my computer, I will totally use Python to create a network
connection and transfer data. I'm just not going to concern myself
with the low-level details when I do.

ChrisA

 

[Skybuck Flying]

"
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?
"

Anything that needs to be super reliable.

My experience so far with Python versus Delphi has shown that Python
requires way more time to debug than Delphi.

The reason for this is the interpreter versus the compiler.

Delphi's compiler will catch many bugs in branches that have not been
executed or tested.

While Python's interpreter will mostly catch bugs in executed and tested
branches.

Most of the code that has not been executed yet could contain bugs and even
syntax/typos/non declared variables and so forth.

Which means that the entire Python program will have to be re-executed from
the start to ultimately end up in branches that were not executed the last
time.

This way of debugging will require many many many many many many many many
runs of the same Python program before it's somewhat debugged.

This is time lost in the debugging phase.

Having said that... time is gained in the programming phase thanks to it's
shortened syntax.

However there is more... Python may lack some technical language elements
like, call by reference, and perhaps other low level codes, like 8 bit, 16
bit, 32 bit integers which play a roll with interfacing with hardware.

Types of software which would not go onto my python list: operating systems,
drivers, perhaps also virtual machines and even compilers, python slow
execution speed hampers that as well.

Bye,
Skybuck.

 

[Chris Angelico]

Anything that needs to be super reliable.

My experience so far with Python versus Delphi has shown that Python
requires way more time to debug than Delphi.

The reason for this is the interpreter versus the compiler.

Delphi's compiler will catch many bugs in branches that have not been
executed or tested.

While Python's interpreter will mostly catch bugs in executed and tested
branches.

What this means is that Python forces you to have a good test suite.
Yes, that is a cost; but it's nothing to do with compiled vs
interpreted. These days, language engines aren't strictly one or the
other, they're on a scale. Python will catch syntactic errors at
compile time, but will catch most other forms of error at run time...
except for the ones that, regardless of the language used, simply
result in wrong data. So if you're not testing your code, you can't
rely on it, and that's nothing to do with the language.

A language with typed variable declarations can catch at compile-time
a class of error that Python can't catch until run-time. Yep. But that
doesn't actually answer the question: what should Python not be used
for. If you need to trust your code, you need to test it.

However there is more... Python may lack some technical language elements
like, call by reference, and perhaps other low level codes, like 8 bit, 16
bit, 32 bit integers which play a roll with interfacing with hardware.

I've never yet found a desperate need for call-by-reference. In toy
examples, the equivalent functionality can be achieved by treating a
one-element list as a pointer, and dereferencing it just like you
would in C, with [0] at the end. Never needed it in production code,
though. But again, this doesn't cut out a class of application, just a
style of coding.

As to strict-size integers, Python does have a struct module, and
ctypes, both of which are designed for interfacing with hardware or
low-level APIs. For normal work, you don't need to care about that at
all.

Types of software which would not go onto my python list: operating systems,
drivers, perhaps also virtual machines and even compilers, python slow
execution speed hampers that as well.

A virtual machine where machine code is executed in Python? Well,
depends on how fast you need it to be, but yes, that's quite likely to
demand more oomph than your typical Python interpreter can give you.
Although you could probably play ancient 8088 games, actually
interpreting it all on the fly; on modern hardware, you could probably
get up to the speed of those old CPUs. Of course, if you can get most
of the work done at a lower level, then it's not that kind of VM, and
performance is completely different.

Compilers... yes, on big projects, you'd probably want to write the
compiler in C. I generally say that C is for writing operating systems
and high level languages, and those high level languages are for
writing everything else in. But look at PyPy. It's possible to write a
Python compiler in Python, which can often out-perform CPython. So
it's not so clear-cut

ChrisA

 

[wxjmfauth]

Le dimanche 9 février 2014 06:17:03 UTC+1, Skybuck Flying a écrit :

"




However there is more... Python may lack some technical language elements

like, call by reference, and perhaps other low level codes, like 8 bit, 16

bit, 32 bit integers which play a roll with interfacing with hardware.

Or, pure software, interfacing with the unicode transformation units!

jmf

 

[Mark Lawrence]

Le dimanche 9 février 2014 06:17:03 UTC+1, Skybuck Flying a écrit :

Or, pure software, interfacing with the unicode transformation units!

jmf

You missed this

 

[Anssi Saari]

btw, Python could be language of choice for embedded systems if small footprint
vm could be developed. had seen similar for java having 10-20 KB byte sized
interpreter with very limited set of functions.

Well, there's the newish Micro python project. Its footprint is
apparently about 60 kB at a minimum (Thumb2 code on ARM). Their
kickstarter is at
https://www.kickstarter.com/projects/214379695/micro-python-python-for-microcontrollers
and source at https://github.com/micropython/micropython

The kickstarter was for funding development and a small board with ST's
Cortex-M4 on it. The source code includes Windows and Unix targets so
it's easy to experiment with without a board too.

 

[Grant Edwards]

Heavy computation might be unideal in Python, but if you can grunge
it into NumPy operations, that won't be a problem.

While one might thing Python is not suitable for heavy number
crunching, it actually gets used for that a lot due to the wide
variety of hard-core number-crunching libraries[1] available (BLAS,
LINPACK, LAPACK, and the sort of thing usually associated with boffins
writin FORTRAN programs). If you're interestedin that sort of stuff,
check out Scientific Python, SciPy, et al.

http://www.scipy.org/
http://en.wikipedia.org/wiki/ScientificPython/
https://wiki.python.org/moin/NumericAndScientific

For extra geek-points you run them on the Fermilab/CERN "Scientific
Linux" distro:

https://www.scientificlinux.org/

You can also get a Python distribution with all the extra geekyness
already baked in:

https://www.enthought.com/products/epd/

[1] Some of those libraries are in FORTRAN because I guess there are
some sorts of numerical hocus-pocus that still writes easier and
runs faster in FORTRAN than in C.

 

[Steven D'Aprano]

"
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? "

Anything that needs to be super reliable.

Obvious troll is obvious.

Okay, I'll bite. What evidence do you have that programs written in
Python are more bug-ridden or less reliable than programs written in
other languages? Your own poorly written, buggy software doesn't count as
evidence. Hypothetical arguments based on "it stands to reason" or
"everybody knows" that static-typed compilers catch more bugs don't count
either. Let's see some hard, reliable statistics.

My experience so far with Python versus Delphi has shown that Python
requires way more time to debug than Delphi.

I'm sorry to hear that you aren't yet fluent at reading, writing and
debugging Python code. While it's true that somebody can write hard-to-
debug code in any language, in general Python's ease of us, dynamic but
not too dynamic nature, and powerful introspection makes debugging quite
easy.

The reason for this is the interpreter versus the compiler.

Which interpreter is that? Do you understand that Python has a compiler?
There's even a "compile" built-in function which compiles source code at
runtime, ready to run it whenever you like.

Delphi's compiler will catch many bugs in branches that have not been
executed or tested.

Only if you write many bugs. You can't catch bugs that aren't there *wink*

But seriously, Delphi's compiler will catch a tiny subset of all possible
bugs, namely, those which can be recognised by static type-checking.
While that's useful, it doesn't happen for free. The cost is that Delphi,
like Pascal, is a lot less flexible, and a lot more tightly constrained
by the need to keep the compiler happy. Although Delphi does have type
inference, it is apparently quite limited, which means you're writing a
lot more boilerplate code declaring types compared to Python.

While Python's interpreter will mostly catch bugs in executed and tested
branches.

Most of the code that has not been executed yet could contain bugs and
even syntax/typos/non declared variables and so forth.

Deary deary me, you've just exposed yourself as somebody who doesn't
actually know much about Python. Non-declared variables? Python doesn't
require declarations for variables.

Nor can syntax errors hide in code branches that haven't been run. (Well,
technically they could, if you use eval or exec.) But for normal code, it
is checked for syntax errors during the compilation phase, all at once.

Which means that the entire Python program will have to be re-executed
from the start to ultimately end up in branches that were not executed
the last time.

That's certainly true. But the same applies to Delphi. Type errors and
syntax errors are only a tiny subset of all the possible errors. You can
have off-by-one errors, logic errors, out-of-bounds errors, network
errors, database errors, file system errors... Delphi can't check for
those at compile time. No matter how clever the programmer or the
compiler, code that hasn't been run and tested cannot be trusted to be
correct. As Donald Knuth said:

Beware of bugs in the above code; I have only proved it
correct, not tried it.

This way of debugging will require many many many many many many many
many runs of the same Python program before it's somewhat debugged.

And if your Delphi code doesn't have just as many many many many many
many many many runs, it won't be debugged either.

This is time lost in the debugging phase.

Having said that... time is gained in the programming phase thanks to
it's shortened syntax.

However there is more... Python may lack some technical language
elements like, call by reference, and perhaps other low level codes,
like 8 bit, 16 bit, 32 bit integers which play a roll with interfacing
with hardware.

Call by reference is a means to an end, not an end to itself. Apart from
that, all those things you say Python "may" lack, it actually has.

Types of software which would not go onto my python list: operating
systems, drivers, perhaps also virtual machines and even compilers,
python slow execution speed hampers that as well.

Agree with the first three. Not so much the last one. Perhaps you have
heard of PyPy? It's not just an optimizing Python compiler, but a more
general compiler-building tool.

 

[CM]

PyPy can generate code which is comparable to compiled C in speed.
Perhaps you mean, "if execution speed is the most important thing, using
a naive Python interpreter may not be fast enough".

Given that the OP seems to be new enough to Python to not know what it is
not as good for, my guess is that PyPy may not yet be "ready enough" to
serve some/most of his needs. For example, if he wanted to write a GUI
app, AFAIK he is, for now, limited to Tkinter and a constrained section of
wxPython, and wxPython is dicey. I tend to see things through a desktop GUI
application lens, so maybe this is just my bias. And I hope I am wrong. I
am in no way trying to slight the PyPy efforts.

Maybe he could somehow write the GUI part with CPython and the speed-critical
parts with PyPy but I don't know if that is possible. (Is it?)

 

[Tim Daneliuk]

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?

Anything requiring strict time determinism - interrupt handlers, hard realtime, etc.

Embedded software (stuff going into ROM).

Virtual memory managers or any other core part of a OS that manipulates hardware.
It can be done with a minimal lower language shim to the hardware, but it likely
would be slooooowwwww.

Life-critical (life support, weapons control, etc.) unless you're willing to
strictly avoid the runtime dynamism of the language. When life and limb are
at stake you want a very static language with strong type enforcement
and lots of assertion checks. In principle, you can certainly do this
in Python, but the language naturally encourages dynamic typing, introspection,
and other, similar runtime behaviors.

Applications where storage for programs is at a premium such as Atmel and
PIC microcontrollers with onboard flash.

Applications in which you do not want the casual reader to be able to
derive the meaning of the source code.

 

[Chris Angelico]

Given that the OP seems to be new enough to Python to not know what it is
not as good for, my guess is that PyPy may not yet be "ready enough" to
serve some/most of his needs. For example, if he wanted to write a GUI
app, AFAIK he is, for now, limited to Tkinter and a constrained section of
wxPython, and wxPython is dicey. I tend to see things through a desktop GUI
application lens, so maybe this is just my bias. And I hope I am wrong. I
am in no way trying to slight the PyPy efforts.

Maybe he could somehow write the GUI part with CPython and the speed-critical
parts with PyPy but I don't know if that is possible. (Is it?)

More likely, he can write the whole thing in Python, and then run it
in CPython. Then see if its speed is good enough. Sometimes "good
enough" means "finishes executing in less than 100ms after user
interaction". Sometimes it's even more generous. Other times it's "can
handle at least X requests per second on a single CPU core", where X
is defined based on the number of requests that the network can
handle. If it meets that requirement, there's no reason to go to any
sort of effort to improve performance. And that's how it is for huge
HUGE numbers of Python scripts.

Of course, if performance _is_ a problem, then the next step is to
measure and find out exactly what's the slow bit. It's seldom what you
first think of.

ChrisA

 

[Steven D'Aprano]

[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?

 

[Tim Daneliuk]

[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