What python can NOT do?

[Tomasz Rola]

On Sat, 29 Aug 2009, Steven D'Aprano wrote:

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

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:tomasz_rola at bigfoot.com             **