What python can NOT do?
qwe rty
an operating system or system drivers.
what else can NOT be done in python? what are the limitations of the
language?
Christian Heimes
Python is a high level language. It's not designed for low level stuff
like bit operations or direct hardware access. However it can be used as
a glue language for low level code written in C or ASM.
Christian
r
> what else can NOT be done in python? what are the limitations of the
> language?
Why would you even want to know what can't be done? What is it that
you would like to do with Python? If you want a one size fits all
language you may be looking for a very long time...
Tim Chase
> i know that an interpreted language like python can't be used to make
> an operating system or system drivers.
As long as you are willing to write the OS hooks in C, you can
write the userspace device drivers in Python:
Since Python is Turing-complete, there's no reason a whole OS
couldn't be authored in Python.
> what else can NOT be done in python? what are the limitations of the
> language?
I understand there's a little trouble getting Python to prove
that P=NP You'll also find that it only comes close to solving
the unrestricted three-body problem and the Traveling Salesman
problem is still limited to fallible heuristics and searching the
entire solution set in better than O(2**n) time.
-tkc
Tim Chase
>> language?
>
> that P=NP You'll also find that it only comes close to solving
> the unrestricted three-body problem and the Traveling Salesman
> problem is still limited to fallible heuristics and searching the
> entire solution set in better than O(2**n) time.
I forgot about solving the Spam problem entirely. And answering
poorly worded/thought-out questions on the internet...
I've also been sorely disappointed by Python's ability to make a
good chocolate cream silk pie.
-tkc
qwe rty
if you don't know the answer please don't reply
r
(snip)
> Since Python is Turing-complete, there's no reason a whole OS
> couldn't be authored in Python.
Yes, and one could go from NY to LA on a unicycle but would one really
want to? Talk about some redass and blueballs! *yikes*
Yes, if i have learned anything in my life, i can say there are
absolutely no boundaries to what humans can achieve short the limit of
their own imagination and the ever fading remainder of ones life.
Steven D'Aprano
> 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
Bruce C. Baker
"qwe rty" <hkh0...@gmail.com> wrote in message
news:00a36f89-52dd-4d90...@q5g2000yqh.googlegroups.com...
It's a floor wax and a dessert topping too! :-)
Tim Chase
I'm not sure you understand -- Being a Turing complete language,
anything you can do in any other language, you can do in Python.
As "r" observed, it might not be a pleasant experience (though
there are a lot of things I'd rather do in Python than in C or
Assembly) but certainly doable.
So clearly the issue resides in your nonsensical question. You
asked for things you can't do with Python so I listed some. The
things you can't do in Python are things you can't do in any
other language either. To turn your snark on end, "If you can't
post a sensible question, please don't post in the first place".
But this is usenet, and Python can't solve the problem of
nonsensical questions posted on usenet. :-/
-tkc
qwe rty
> > if you don't know the answer please don't reply
>
> I'm not sure you understand -- Being a Turing complete language,
> anything you can do in any other language, you can do in Python.
> As "r" observed, it might not be a pleasant experience (though
> there are a lot of things I'd rather do in Python than in C or
> Assembly) but certainly doable.
>
> So clearly the issue resides in your nonsensical question. You
> asked for things you can't do with Python so I listed some. The
> things you can't do in Python are things you can't do in any
> other language either. To turn your snark on end, "If you can't
> post a sensible question, please don't post in the first place".
>
> But this is usenet, and Python can't solve the problem of
> nonsensical questions posted on usenet. :-/
>
> -tkc
i am free to post , you are free to ignore
qwe rty
thank you very much ,THIS is the sort of answer i wanted
Nobody
>> Since Python is Turing-complete, there's no reason a whole OS
>> couldn't be authored in Python.
>
> Yes, and one could go from NY to LA on a unicycle but would one really
> want to? Talk about some redass and blueballs! *yikes*
>
> Yes, if i have learned anything in my life, i can say there are
> absolutely no boundaries to what humans can achieve short the limit of
> their own imagination and the ever fading remainder of ones life.
Well, other than writing a program to determine whether a program in a
Turing-complete language will terminate on some input, or devising a
formal system which is sound, complete, and able to express its own
metatheory, or ...
Some things are actually impossible.
Nobody
> if you don't know the answer please don't reply
If you don't understand the question, don't post it in the first place.
qwe rty
don't be so angry ,not good for your health
Tomasz Rola
Oh, my. And now everybody points at you this Turing-completeness. The
issue, in my opinion, is not that something cannot be done. The truth
about Turing-completeness is, I would say, you can do whatever but
sometimes you will not because it would be too ugly. My private list of
things that when implemented in Python would be ugly to the point of
calling it difficult:
1. AMB operator - my very favourite. In one sentence, either language
allows one to do it easily or one would not want to do it (in an ugly
way).
http://www.randomhacks.net/articles/2005/10/11/amb-operator
After quite some googling I was finally able to locate sample
implementation, but I cannot say ATM how well it works and if it is
practical enough to use it in any of my programs. If time permits, I will
try it, hopefully.
http://www.c2.com/cgi/wiki?AmbInPython
2. Changing the language from the inside.
Everybody can change the interpreter, right? But how about doing some
bigger, maybe even fundamental change to the language by means offered by
the language itself?
Example:
If Python had no object system, or if I wanted to implement one in
different way (say, I would like to experiment or I would not want to wait
for a new release). In some languages that interest me now, it is possible
and practical, more or less. So it can sometimes backfire - what OO system
should I choose for my next Scheme program, etc. Because there are few of
them :-), all (? - I believe) implemented as a code library. Just install
it and off you go, now you have OO programming. Actually, I don't use OO
all that much recently (maybe I feel disapointed a bit, or something).
Also, I have read (but not checked it myself) that for some time Common
Lisp had it's now-official CLOS distributed and tested in a form of
library. Say, have they adopted OO with single inheritance as a part of CL
ANSI standard - I would still be able to have OO with multiple
inheritance. I would just have to download and install CLOS. No change to
interpreter or compiler. From their point of view, CLOS would be just
another library.
http://en.wikipedia.org/wiki/Common_Lisp_Object_System
Judging by this code, introducing OO to the language is relatively easy:
http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme-Z-H-14.html
It is not possible to alter Python in a minor way, I think. Something
simpler than OO, like a new keyword or structures:
http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme-Z-H-10.html
http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme-Z-H-11.html
Some readers could oppose the above by saying that Lisp's syntax is so
primitive that it can be used to implement just any programming paradigm,
so having it as a loadable code is not a big achievement. Well, it seems
to me that Python has even simpler syntax or on par with Lisp family,
so...
Some (perhaps other) readers could also say, that there is no need to
extend Python. It already has sets and "yield" and... But some time ago it
did not. As far as I can tell, it can be a bit too hard to go into
"experimenting mode" with Python. Something like adding "yield" all but
myself. It only takes few kilos of code for a working OO in another
language, so how hard could such "yield" be? Well, in Python I probably
wouldn't dare.
BTW I hope nobody's feeling have been hurt. This was meant to be
informative, not offensive.
BTW2. As I said, these are _possible_ things (Turing complete language,
and so on). But adding them would require some hard work and would produce
ugly and/or fragile code, so I decided it could be easier to learn another
language...
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomas...@bigfoot.com **
Aahz
qwe rty <hkh0...@gmail.com> wrote:
>
>> > if you don't know the answer please don't reply
>>
>> I'm not sure you understand -- Being a Turing complete language,
>> anything you can do in any other language, you can do in Python.
>> there are a lot of things I'd rather do in Python than in C or
>> Assembly) but certainly doable.
>>
>> asked for things you can't do with Python so I listed some. =A0The
>> things you can't do in Python are things you can't do in any
>> post a sensible question, please don't post in the first place".
>>
>> But this is usenet, and Python can't solve the problem of
>> nonsensical questions posted on usenet. :-/
>>
>> -tkc
>
>i am free to post , you are free to ignore
Well -- don't you think the same applies in reverse? Remember that
Python is named after the comedy group Monty Python, and jokes are a
frequent occurrence on this group.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"I support family values -- Addams family values" --www.nancybuttons.com
Steven D'Aprano
> My private list of
> things that when implemented in Python would be ugly to the point of
> calling it difficult:
>
> 1. AMB operator - my very favourite. In one sentence, either language
> allows one to do it easily or one would not want to do it (in an ugly
> way).
>
> http://www.randomhacks.net/articles/2005/10/11/amb-operator
Fascinating, but I don't exactly see how that's actually *useful*. It
strikes me of combining all the benefits of COME FROM with the potential
performance of Bogosort, but maybe I'm being harsh.
On the other hand, it sounds rather like Prolog-like declarative
programming. I fear that, like Prolog, it risks massive performance
degradation if you don't apply the constraints in the right order.
> 2. Changing the language from the inside.
>
> Everybody can change the interpreter, right? But how about doing some
> bigger, maybe even fundamental change to the language by means offered
> by the language itself?
Like Forth. You need it in Forth, because it has a very sparse set of
language features, and everything is bootstrapped from a small set of
commands, so the ability to re-define the language as you go is (1)
necessary and (2) free.
But for Python, I don't know... it sounds cool, but in practice? It
sounds like the sort of thing that allows programmers to spend three
hours writing a new control structure which will save them three minutes.
And of course, for all but the tiniest, one-man-band applications,
readability is important. Sure, you've created a gee-whizz control
structure which combines try, while and if into one keyword, and it
automatically does logging and threading, fantastic. But how will anyone
else be able to maintain it when you're gone?
The ability to change the language is one step into a tarpit, where
everything is possible but nothing is easy, and where you spend all your
time writing language features and none of your time building the useful
functionality you actually want. It sounds like something you want in a
language you use for designing languages, rather than writing
applications.
--
Steven
Hendrik van Rooyen
> I've also been sorely disappointed by Python's ability to make a
> good chocolate cream silk pie.
This is not pythons fault - it is yours, for failing to collaborate with a
good hardware designer for the robotics.
- Hendrik
Timothy N. Tsvetkov
If you want to ask a silly question don't ask it.
Tomasz Rola
> On Aug 29, 4:26�am, qwe rty <hkh00...@gmail.com> wrote:
> > On Aug 29, 3:14�am, Tim Chase <python.l...@tim.thechases.com> wrote:
> >
> > > >> what else can NOT be done in python? what are the limitations of the
> > > >> language?
> >
[...]
> > > I forgot about solving the Spam problem entirely. �And answering
> > > poorly worded/thought-out questions on the internet...
> >
> > > I've also been sorely disappointed by Python's ability to make a
> > > good chocolate cream silk pie.
> >
> > > -tkc
> >
> > if you don't know the answer please don't reply
>
> If you want to ask a silly question don't ask it.
The question the OP asked was not silly.
Tomasz Rola
> On Sat, 29 Aug 2009 05:37:34 +0200, Tomasz Rola wrote:
>
> > My private list of
> > things that when implemented in Python would be ugly to the point of
> > calling it difficult:
> >
> > 1. AMB operator - my very favourite. In one sentence, either language
> > allows one to do it easily or one would not want to do it (in an ugly
> > way).
> >
> > http://www.randomhacks.net/articles/2005/10/11/amb-operator
>
>
> Fascinating, but I don't exactly see how that's actually *useful*. It
> strikes me of combining all the benefits of COME FROM with the potential
> performance of Bogosort, but maybe I'm being harsh.
Usefullness is totally different thing, I agree. However, amb could still
find some following. I guess it is more about personal taste and
willingness to look for better idioms in programming. I can imagine when
they introduced for and while loops, people were pointing at conditional
goto as more practical (I think every control structure can be modeled
with it).
Id doesn't mean amb is better idiom, but it is something that could be
tried - or not. One could write like this:
(partially stol####copied from the above link)
a = amb 1, 2, 3
b = amb 4, 5, 6
c = amb 7, 8, 9
if a*b + c != 27 :
amb
print a,b,c
or one could write like this:
for a in [1, 2, 3]:
for b in [4, 5, 6]:
for c in [7, 8, 9]:
if a*b+c == 27 :
print a,b,c
break
Which one would I choose? Well, amb of course. I consider it to be more
readable which is, for me at least, useful. Now, try to imagine the same
with ten variables. And longer lists. And some problems do not fit well
into numpy (they could be non-numerical in nature).
> On the other hand, it sounds rather like Prolog-like declarative
> programming. I fear that, like Prolog, it risks massive performance
> degradation if you don't apply the constraints in the right order.
Of course, but this can be optimised. Either by hand or by a good
compiler (whatever this means). Performance degradation is connected with
abuse of every other programming technique, too. And besides, I believe
one would sometimes trade performance for the ability to clearly express
the idea behind the algorithm. Just as is the case with choosing Python
rather than Java. For things I use Python for, I wouldn't use Java or C.
Even though C is one of my beloved languages. If I ever used Prolog for
anything, I wouldn't like to rewrite it in C or Python. I mean, languages
should (in theory) be chosen and used with some consideration.
> > 2. Changing the language from the inside.
> >
> > Everybody can change the interpreter, right? But how about doing some
> > bigger, maybe even fundamental change to the language by means offered
> > by the language itself?
>
> Like Forth. You need it in Forth, because it has a very sparse set of
> language features, and everything is bootstrapped from a small set of
> commands, so the ability to re-define the language as you go is (1)
> necessary and (2) free.
It also leads to writing code in an incredibly expressive manner. I've
never done anything big in Forth. I only had a two weeks long exposure to
it in times, when you loaded such things from casette recorder ;-/... But
from time to time I find some interesting pieces, like a disk driver whose
source would fit into a comment of one Python function :-).
> But for Python, I don't know... it sounds cool, but in practice? It
> sounds like the sort of thing that allows programmers to spend three
> hours writing a new control structure which will save them three minutes.
It really is not so. Writing something for three hours and using it only
once sounds more like programming excercise, less like real life work. To
write a function I need to know at least two places in my code where it
would be used (well, I am oversimplifying, ok? sometimes one place is
sufficient). I think reasonable people would judge language extension by
similar criteria. They would possibly stay away from this as long as
possible (I have such possibility from some time but I just don't touch
macros, which by my own words makes me reasonable, wow :-)... or a
coward...).
> And of course, for all but the tiniest, one-man-band applications,
> readability is important. Sure, you've created a gee-whizz control
> structure which combines try, while and if into one keyword, and it
> automatically does logging and threading, fantastic. But how will anyone
> else be able to maintain it when you're gone?
This is comparable to me creating a gee-whizz function library and using
it. I cannot see a problem as long as I document (with use cases, tests
etc).
There is something better in this idea. Suppose I would have invented a
better control structure and posted the source code here? Some would have
found it amusing, others would have tried it, posted their comments,
leading to improvements and further spreading. Finally - who knows - it
could have found a way in to a standard. And even if not, it should still
remain as a loadable extension for quite some time.
> The ability to change the language is one step into a tarpit, where
> everything is possible but nothing is easy, and where you spend all your
> time writing language features and none of your time building the useful
> functionality you actually want.
I don't think this is much different from the situation when I would write
string processing library (that would be used further in the program)
rather than "building useful functionality" - which would be what,
programming buttons :-)?
For me, it looks like language elements should not be protected from my
tinkering. Think about operators in Python. I can define my own "+" for
some objects, which has been decided on Python's upper levels :-). In
fact, as far as I remember, I have never used this feature. But knowing
there is some possibility, space to grow, is good.
> It sounds like something you want in a
> language you use for designing languages, rather than writing
> applications.
Yes indeed, Lisps have been used to prototype some other languages.
However, I am not sure if the boundary between a language and an app could
be strictly defined. If adding new words to the language dictionary by
writing a library is considered a good programming practice, then why
adding a new keyword and syntax should not be considered as such?
Ok, since I myself have written above I didn't use those features from
very upper shelve, one could ask what is my point. The point is, if I
wanted to, I could have used them. Click and go. Do anything that by my
own judgement is good for code progress rather than murmuring about my
code being less elegant and expressive that it could have been. I mean, if
my job was beheading people, I would rather do it with sharp axe because
it is more expressive and elegant than sawing their necks with piece of
wood. And besides the job is better done and less boring for parties
involved. So, my going after elegance is not so much whimsical, at least
not from my point of view. I believe there is something more to it than
just esthetics.
Just in case - I am not voting for changes in Python. Quite far from this.
Only expressing my opinions etc. As I have already mentioned in some other
posts of mine, Python is good for few things I do and for other things I
use other tools. That's it.
John Nagle
Speed, basically. CPython is on the slow side. This is not
inherent in the language; it's an implementation problem.
The Shed Skin compiler is approaching C speeds,
but you have to accept some modest restrictions on run-time dynamism.
Also, CPython does not use multiple processors well. In fact,
multiple cores make CPython performance worse. (There's a long
analysis of this that's been discussed here recently.)
Personally, I consider Python to be a good language held back by
too-close ties to a naive interpreter implementation and the lack
of a formal standard for the language.
John Nagle
Aahz
John Nagle <na...@animats.com> wrote:
>
> Personally, I consider Python to be a good language held back by
>too-close ties to a naive interpreter implementation and the lack
>of a formal standard for the language.
Name one language under active development that has not been harmed by a
formal standard. (I think C doesn't count -- there was relatively little
development of C after the standards process started.)
exa...@twistedmatrix.com
>In article <4a998465$0$1637$742e...@news.sonic.net>,
>John Nagle <na...@animats.com> wrote:
>>
>> Personally, I consider Python to be a good language held back by
>>too-close ties to a naive interpreter implementation and the lack
>>of a formal standard for the language.
>
>Name one language under active development that has not been harmed by
>a
>formal standard. (I think C doesn't count -- there was relatively
>little
>development of C after the standards process started.)
I think you must mean "harmed by a formal standard more than it has been
helped", since that's clearly the interesting thing.
And it's a pretty difficult question to answer. How do you quantify the
harm done to a language by a standarization process? How do you
quantify the help? These are extremely difficult things to measure
objectively.
For my part, I will agree with John. I feel like Python's big
shortcomings stem from the areas he mentioned. They're related to each
other as well - the lack of a standard hampers the development of a less
naive interpreter (either one based on CPython or another one). It
doesn't completely prevent such development (obviously, as CPython
continues to undergo development, and there are a number of alternate
runtimes for Python-like languages), but there's clearly a cost
associated with the fact that in order to do this development, a lot of
time has to be spent figuring out what Python *is*. This is the kind of
thing that a standard would help with.
Jean-Paul
AggieDan04
> > i know that an interpreted language like python can't be used to make
> > an operating system or system drivers.
>
> As long as you are willing to write the OS hooks in C, you can
> write the userspace device drivers in Python:
Writing your OS hooks in C isn't a problem because you could write a C
compiler in Python ;-)
Che M
> i know that an interpreted language like python can't be used to make
> an operating system or system drivers.
>
> language?
Now that you have some good answers, may I ask what what your reason
was for posting this question?
Michael Torrie
You forgot your smiley emoticon! Since everyone else is posting in a
light-hearted manner (not "angry" as you say), I choose to read your
post in this light as well.
What Nobody was really trying to say, is ask your question in a better
way and you'll get a better answer.
Terry Reedy
> For my part, I will agree with John. I feel like Python's big
> shortcomings stem from the areas he mentioned. They're related to each
> other as well - the lack of a standard hampers the development of a less
> naive interpreter (either one based on CPython or another one).
The reference manual is *intended* to define the 'standard' Python
language.
> It
> doesn't completely prevent such development (obviously, as CPython
> continues to undergo development, and there are a number of alternate
> runtimes for Python-like languages), but there's clearly a cost
> associated with the fact that in order to do this development, a lot of
> time has to be spent figuring out what Python *is*. This is the kind of
> thing that a standard would help with.
Such developers occasionally raise questions about ambiguities in the
ref manual on the pydev list. This is part of the editing process.
There is an effort underway to separate the CPython test suite into two
parts: test of standard Python behavior, which all implementations
should pass, and tests of the CPython implementation, which other
implementations need not pass. It will move as fast as volunteer effort
moves it.
tjr
Joshua Judson Rosen
>
> On Sat, 29 Aug 2009 05:37:34 +0200, Tomasz Rola wrote:
>
> > My private list of things that when implemented in Python would be
> > ugly to the point of calling it difficult:
> >
> > 1. AMB operator - my very favourite. In one sentence, either language
> > allows one to do it easily or one would not want to do it (in an ugly
> > way).
> >
> > http://www.randomhacks.net/articles/2005/10/11/amb-operator
>
>
> Fascinating, but I don't exactly see how that's actually *useful*. It
> strikes me of combining all the benefits of COME FROM with the potential
> performance of Bogosort, but maybe I'm being harsh.
There's a chapter on this (non-deterministic computing in general,
and `amb' in particular) in Abelson's & Sussman's book,
`Structure and Interpretation of Computer Programs':
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-28.html#%_sec_4.3
It's an interesting read (the chapter, as well as the rest of the book).
> On the other hand, it sounds rather like Prolog-like declarative
> programming. I fear that, like Prolog, it risks massive performance
> degradation if you don't apply the constraints in the right order.
One of the classic arguments in the other direction is that
imperative programming (as is common in Python ;)) risks
massive *incorrect results* if you don't apply the side-effects
in the right order :)
--
Don't be afraid to ask (Lf.((Lx.xx) (Lr.f(rr)))).
Nobody
>>> Personally, I consider Python to be a good language held back by
>>>too-close ties to a naive interpreter implementation and the lack
>>>of a formal standard for the language.
>>
>>Name one language under active development that has not been harmed by a
>>formal standard. (I think C doesn't count -- there was relatively little
>>development of C after the standards process started.)
>
> I think you must mean "harmed by a formal standard more than it has been
> helped", since that's clearly the interesting thing.
>
> And it's a pretty difficult question to answer. How do you quantify the
> harm done to a language by a standarization process? How do you
> quantify the help? These are extremely difficult things to measure
> objectively.
For a start, you have to decide how to weight the different groups of
users.
For an application which is designed for end users and will be in a
permanent state of flux, dealing with revisions to the language or its
standard libraries are likely to be a small part of the ongoing
development effort.
For libraries or middleware which need to maintain a stable interface, or
for code which needs extensive testing, documentation, audits, etc, even a
minor update can incur significant costs.
Users in the latter group will prefer languages with a stable and rigorous
specification, and will tend to view any flexibility granted to the
language implementors as an inconvenience.
John Nagle
> On 10:23 pm, aa...@pythoncraft.com wrote:
>> In article <4a998465$0$1637$742e...@news.sonic.net>,
>> John Nagle <na...@animats.com> wrote:
>>>
>>> Personally, I consider Python to be a good language held back by
>>> too-close ties to a naive interpreter implementation and the lack
>>> of a formal standard for the language.
>
> For my part, I will agree with John. I feel like Python's big
> shortcomings stem from the areas he mentioned. They're related to each
> other as well - the lack of a standard hampers the development of a less
> naive interpreter (either one based on CPython or another one). It
> doesn't completely prevent such development (obviously, as CPython
> continues to undergo development, and there are a number of alternate
> runtimes for Python-like languages), but there's clearly a cost
> associated with the fact that in order to do this development, a lot of
> time has to be spent figuring out what Python *is*. This is the kind of
> thing that a standard would help with.
Right. Python is a moving target for developers of implementations other
than CPython. IronPython's production version is at Python 2.5, with a
beta at 2.6. Shed Skin is at 2.x and lacks the manpower to get to 3.x.
Psyco I'm not sure about, but it's 2.x. PyPy is at Python 2.5, but PyPy
is currently slower than CPython.
A solid Python 3 standard would give everyone a target to shoot for that
would be good for five years or so.
John Nagle
Mike Coleman
> i know that an interpreted language like python can't be used to make
> an operating system or system drivers.
>
> what else can NOT be done in python? what are the limitations of the
> language?
Neither of those is strictly true. It is true, though, that Python
cannot be used to write arbitrarily complex one-liners, though.
MRAB
Why not? You could put the code in a string literal and then use 'exec',
all in one source line.
Steven D'Aprano
> It is true, though, that Python
> cannot be used to write arbitrarily complex one-liners, though.
Incorrect.
>>> exec "x=1\0while x < 5:\0 x+=1\0print x".replace('\0','\n')
5
Take (almost) any arbitrary piece of Python code. Replace all newlines by
nulls. Escape any quotation marks. Wrap the whole thing in quotes, and
pass it to exec as above, and you have an arbitrarily complex one-liner.
--
Steven
Grant Edwards
I don't understand the reason for the newline/null swapping.
Why not just do this?
>>> exec "x=1\nwhile x < 5:\n x+=1\nprint x\n"
5
--
Grant
Steven D'Aprano
>> Take (almost) any arbitrary piece of Python code. Replace all newlines
>> by nulls. Escape any quotation marks. Wrap the whole thing in quotes,
>> and pass it to exec as above, and you have an arbitrarily complex
>> one-liner.
>
> I don't understand the reason for the newline/null swapping.
Good point. I was just over-complicating it. Oops.
--
Steven
Albert van der Horst
>
>> i know that an interpreted language like python
>
>interpreted or compiled.
<SNIP>
Thanks for an excellent overview. There is this one point I
don't understand:
>Existing Python implementations don't give you direct access to hardware,
>and bit-manipulation has a lot of overhead in Python. Numerical
Surely you don't mean that
0x17 & 0xAD
has more overhead than
17 + 123
So what do you mean here?
<SNIP>
>
>--
>Steven
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Steven D'Aprano
>>Existing Python implementations don't give you direct access to
>>hardware, and bit-manipulation has a lot of overhead in Python.
>>Numerical
>
> Surely you don't mean that
> 0x17 & 0xAD
> has more overhead than
> 17 + 123
> So what do you mean here?
What I mean is that bit-manipulation in low-level languages like C is
very close to the metal, and hence very efficient. In Python, *all*
operations (including bit-manipulation and arithmetic) has the overhead
of the Python virtual machine. You won't notice the difference if you're
just ANDing a handful of numbers, but if you're doing millions of them
(say, you're doing industrial-strength encryption) you certainly will.
--
Steven
Дамјан Георгиевски
> to write in existing Python implementations.
I wonder if TinyPy (http://www.tinypy.org/) could be used to write a
boot loader. It would probably need some more code to replace the
services it uses from an OS, and perhaps it would need to work in 16bit
program mode on x86 - but maybe it's doable?
tinypy is a minimalist implementation of python in 64k of code
--
дамјан ( http://softver.org.mk/damjan/ )
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan