On Aug 29, 4:17 am, Steven D'Aprano <st...@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 -- http://mail.python.org/mailman/listinfo/python-list
