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	20 on this page of 23 — 16 participants

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

Page 1 of 2 [1] 2 Next page →

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

From	Sam <lightaiyee@gmail.com>
Date	2014-02-08 15:54 -0800
Subject	What are the kinds of software that are not advisable to be developed using Python?
Message-ID	<a584b0e9-1995-4189-bfac-d0c5ffc080c9@googlegroups.com>

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?

[toc] | [next] | [standalone]

#65699

From	Denis McMahon <denismfmcmahon@gmail.com>
Date	2014-02-09 00:09 +0000
Message-ID	<ld6h03$np5$3@dont-email.me>
In reply to	#65698

On Sat, 08 Feb 2014 15:54:30 -0800, 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?

OS Kernels. Hardware drivers.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#65700

From	Chris Angelico <rosuav@gmail.com>
Date	2014-02-09 11:11 +1100
Message-ID	<mailman.6552.1391904688.18130.python-list@python.org>
In reply to	#65698

On Sun, Feb 9, 2014 at 10:54 AM, Sam <lightaiyee@gmail.com> 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?
>

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

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

#65832

From	Grant Edwards <invalid@invalid.invalid>
Date	2014-02-10 16:54 +0000
Message-ID	<ldb07i$a30$1@reader1.panix.com>
In reply to	#65700

On 2014-02-09, Chris Angelico <rosuav@gmail.com> wrote:

> 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.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm ZIPPY the PINHEAD
                                  at               and I'm totally committed
                              gmail.com            to the festive mode.

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

#66891

From	Laurent Pointal <laurent.pointal@free.fr>
Date	2014-02-22 12:15 +0100
Message-ID	<530886d8$0$2301$426a74cc@news.free.fr>
In reply to	#65700

Chris Angelico wrote:

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

May take a look to Pythran too, which generate C++ code from (limited subset 
of) Python code, usable as a Python compiled module or as standalone C++.

https://github.com/serge-sans-paille/pythran

A+
Laurent.

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

#65710

From	Roy Smith <roy@panix.com>
Date	2014-02-08 21:53 -0500
Message-ID	<roy-2ECF2F.21530008022014@news.panix.com>
In reply to	#65698

In article <a584b0e9-1995-4189-bfac-d0c5ffc080c9@googlegroups.com>,
 Sam <lightaiyee@gmail.com> 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?

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.

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

#65718

From	Steven D'Aprano <steve+comp.lang.python@pearwood.info>
Date	2014-02-09 03:43 +0000
Message-ID	<52f6f973$0$29972$c3e8da3$5496439d@news.astraweb.com>
In reply to	#65710

On Sat, 08 Feb 2014 21:53:00 -0500, Roy Smith wrote:

> In article <a584b0e9-1995-4189-bfac-d0c5ffc080c9@googlegroups.com>,
>  Sam <lightaiyee@gmail.com> 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?
> 
> 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.

-- 
Steven

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

#65720

From	Asaf Las <roegltd@gmail.com>
Date	2014-02-08 20:09 -0800
Message-ID	<4fb34e9b-d2f0-432b-852e-55177a38167c@googlegroups.com>
In reply to	#65718

On Sunday, February 9, 2014 5:43:47 AM UTC+2, Steven D'Aprano wrote:
> 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.

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

#65803

From	Anssi Saari <as@sci.fi>
Date	2014-02-10 12:10 +0200
Message-ID	<vg3lhxj1doe.fsf@coffee.modeemi.fi>
In reply to	#65720

Asaf Las <roegltd@gmail.com> writes:

> 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.

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

#65878

From	CM <cmpython@gmail.com>
Date	2014-02-10 20:21 -0800
Message-ID	<b0af015c-ba84-4360-a2f6-4e7882254649@googlegroups.com>
In reply to	#65718

On Saturday, February 8, 2014 10:43:47 PM UTC-5, Steven D'Aprano wrote:

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

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

#65882

From	Chris Angelico <rosuav@gmail.com>
Date	2014-02-11 15:59 +1100
Message-ID	<mailman.6649.1392094783.18130.python-list@python.org>
In reply to	#65878

On Tue, Feb 11, 2014 at 3:21 PM, CM <cmpython@gmail.com> wrote:
> On Saturday, February 8, 2014 10:43:47 PM UTC-5, Steven D'Aprano wrote:
>
>> 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?)

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

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

#65719

From	Michael Torrie <torriem@gmail.com>
Date	2014-02-08 21:08 -0700
Message-ID	<mailman.6567.1391918947.18130.python-list@python.org>
In reply to	#65698

On 02/08/2014 05:11 PM, Chris Angelico wrote:
> On Sun, Feb 9, 2014 at 10:54 AM, Sam <lightaiyee@gmail.com> 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?
>>
> 
> 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.

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

#65721

From	Chris Angelico <rosuav@gmail.com>
Date	2014-02-09 15:14 +1100
Message-ID	<mailman.6568.1391919286.18130.python-list@python.org>
In reply to	#65698

On Sun, Feb 9, 2014 at 3:08 PM, Michael Torrie <torriem@gmail.com> wrote:
> On 02/08/2014 05:11 PM, Chris Angelico wrote:
>> On Sun, Feb 9, 2014 at 10:54 AM, Sam <lightaiyee@gmail.com> 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?
>>>
>>
>> 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.

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

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

#65722

From	"Skybuck Flying" <Windows7IsOK@DreamPC2006.com>
Date	2014-02-09 06:17 +0100
Message-ID	<4ffa1$52f70f30$5419b3e4$9454@cache1.tilbu1.nb.home.nl>
In reply to	#65698

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

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

#65724

From	Chris Angelico <rosuav@gmail.com>
Date	2014-02-09 16:41 +1100
Message-ID	<mailman.6569.1391924507.18130.python-list@python.org>
In reply to	#65722

On Sun, Feb 9, 2014 at 4:17 PM, Skybuck Flying
<Windows7IsOK@dreampc2006.com> wrote:
> 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

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

#65738

From	wxjmfauth@gmail.com
Date	2014-02-09 02:47 -0800
Message-ID	<bbde1fb4-1002-482d-b488-f4ea7feebcf8@googlegroups.com>
In reply to	#65722

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

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

#65768

From	Mark Lawrence <breamoreboy@yahoo.co.uk>
Date	2014-02-09 15:49 +0000
Message-ID	<mailman.6594.1391960970.18130.python-list@python.org>
In reply to	#65738

On 09/02/2014 10:47, wxjmfauth@gmail.com wrote:
> 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
>

You missed this :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

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

#65848

From	Steven D'Aprano <steve+comp.lang.python@pearwood.info>
Date	2014-02-10 22:56 +0000
Message-ID	<52f9590f$0$29972$c3e8da3$5496439d@news.astraweb.com>
In reply to	#65722

On Sun, 09 Feb 2014 06:17:03 +0100, Skybuck Flying 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? "
> 
> 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.

-- 
Steven

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

#65881

From	Tim Daneliuk <tundra@tundraware.com>
Date	2014-02-10 22:40 -0600
Message-ID	<g7mosa-j631.ln1@ozzie.tundraware.com>
In reply to	#65698

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

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.

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

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

#65885

From	Steven D'Aprano <steve@pearwood.info>
Date	2014-02-11 05:35 +0000
Message-ID	<52f9b6af$0$11128$c3e8da3@news.astraweb.com>
In reply to	#65881

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?


-- 
Steven

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

Page 1 of 2 [1] 2 Next page →

csiph-web

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

Contents

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

#65699

#65700

#65832

#66891

#65710

#65718

#65720

#65803

#65878

#65882

#65719

#65721

#65722

#65724

#65738

#65768

#65848

#65881

#65885