What python can NOT do?

[qwe rty]

On Aug 29, 4:17 am, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:
> On Fri, 28 Aug 2009 15:37:46 -0700, qwe rty wrote:
> > i know that an interpreted language like python
>
> Languages are neither interpreted nor compiled. *Implementations* are
> interpreted or compiled.
>
> Perl has only one implementation, which is interpreted (as far as I
> know); Java has a number of implementations, some of which compile to
> byte-code, some compile to machine-code. There are C interpreters as well
> as C compilers. And languages like Forth have an unusual programming
> model which doesn't easily match the conventional interpreted/compiled
> distinction.
>
> Python has a number of implementations, all of which are compiled to byte-
> code, like early Java. None are purely interpreted; none are compiled to
> machine-code, although there are add-ons to CPython which will compile
> most Python code to machine-code. Some day, Python may include
> implementations which compile directly to machine-code.
>
> > can't be used to make an operating system or system drivers.
>
> With existing Python implementations, it would be difficult to write an
> OS, because the implementations assume there is already an operating
> system available to handle things like memory and disk IO. So before you
> could write an OS in Python, you would need to write a new Python
> implementation. However, you could easily write a "virtual OS" in Python
> which sat on top of the regular OS.
>
> Device drivers would be less difficult, but performance may be slow
> compared to drivers written in (say) C.
>
> Boot loaders are another type of software which would be impractical to
> write in existing Python implementations.
>
> > what else can NOT be done in python? what are the limitations of the
> > language?
>
> As a language, Python has no theoretical limits -- it is Turing Complete,
> which means anything you can do in C, Java, Lisp, or any other Turing
> Complete language, you could do in Python -- with sufficient effort, and
> provided you don't care about efficiency.
>
> In practice, though, we *do* care about efficiency, and about the effort
> required to write the program in the first case. In practical terms,
> Python the language makes most things easy to write but slower to run, so
> there are very few applications which couldn't be written in Python.
>
> A few things are more difficult than others. One of the hardest things to
> do is to "sandbox" some arbitrary Python code from an untrusted source
> and execute it in a restricted environment.
>
> In practical terms, Python will let you write nearly any sort of program
> you want, provided absolute performance isn't your provided. (To put it
> another way, Python code is rarely "the fastest", but it is usually "fast
> enough".) If performance is too slow, Python is an excellent "glue"
> language, letting you write the bulk of your program in Python for ease,
> the performance-critical parts in C for speed.
>
> Some practical restrictions... if you are writing a web app, some hosting
> providers don't provide access to Python on their webserver, so you're
> limited to using whatever languages they provide, or finding another
> provider.
>
> All existing Python implementations require a minimum amount of memory to
> operate. This is relatively high, so you probably couldn't use Python on
> a device where you only had (say) 64K of memory. There's no Python
> implementation for your ancient Mac Plus or Commodore 64, and there
> probably never will be. Python the language is based on an execution
> model with relatively high overhead, so even if you wrote an
> implementation for such ancient machines, you probably couldn't do much
> with it.
>
> Existing Python implementations don't give you direct access to hardware,
> and bit-manipulation has a lot of overhead in Python. Numerical
> calculations (e.g. scientific array calculations) also suffer from
> overhead, which is barely noticeable if you're doing a few thousand
> calculations, but if you're doing a few tens of millions may be a little
> slow. For these, you should use Python as an interface to numeric
> libraries written in C, like Scipy and Numpy.
>
> --
> Steven

thank you very much ,THIS is the sort of answer i wanted