What python can NOT do?

[Tomasz Rola]

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.

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.

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:[email protected] **

 

[John Nagle]

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?

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

 

[Dennis Lee Bieber]

Theoretically ...
... in
theory.

You're sure that wasn't an hypothesis? <G>

 

[Aahz]

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

 

[exarkun]

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

 

[Dennis Lee Bieber]

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

Or wherein the next standard revision primarily was created to
formalize things that were "added" as extensions to the prior standard
by each of the compiler writers...

 

[AggieDan04]

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.

what else can NOT be done in python? what are the limitations of the
language?

Now that you have some good answers, may I ask what what your reason
was for posting this question?

 

[Michael Torrie]

don't be so angry ,not good for your health

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

 

[Nobody]

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]

....

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]

Neither of those is strictly true. It is true, though, that Python
cannot be used to write arbitrarily complex one-liners, though.

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.

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 D'Aprano]

I don't understand the reason for the newline/null swapping.

Good point. I was just over-complicating it. Oops.

 

[Albert van der Horst]

Languages are neither interpreted nor compiled. *Implementations* are
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?


Groetjes Albert

 

[Steven D'Aprano]

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.

 

[Дамјан ГеоргиевÑки]

Boot loaders are another type of software which would be impractical

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