What python can NOT do?
rtomek at ceti.com.pl
Sat Aug 29 20:18:07 CEST 2009
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
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 :
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 :
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
> 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
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
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 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.
** 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 **
More information about the Python-list