First script, please comment and advise

bearophileHUGS at bearophileHUGS at
Thu Mar 9 21:31:17 CET 2006

This is different too, but maybe a little better than my last version:

from random import shuffle
from itertools import groupby

def scramble_text(text):
    """Return the words in input text string scrambled,
    except for the first and last letter."""
    def scramble(word):
        if len(word) < 4: return "".join(word)
        core = word[1:-1]
        return "".join([word[0]] + core + [word[-1]])

    return "".join(scramble(list(g)) for _,g in groupby(text,

print scramble_text(scramble_text.__doc__)

Just, we can discuss a lot, but it's probably of little use, because
different programmers have different style of programming. If you take
someone that is expert in Lisp or Java (and with some Python
experienxe) you can probably find other possibile solutions of this
same little problem. Sometimes you can ask them to write more pythonic
programs, but you cannot ask them to program exactly as you do.

I can answer some of your points, but it's just a relaxed discussion...

>Luckily this is Python, not Pascal :)

I agree that Python isn't a Pascal-like language, they are usually
compiled, so nested functions have less overhead, and there are other
differences. But Object Pascal has some good parts too, some things are
better than Python ones. Like the sintax of bitwise operators and
%-like formatting, some parts of the the I/O, etc. Many languages are
designed by intelligent people. Lisp, Mathematica, Perl, Ruby, Delphi,
Haskell, D, Smalltalk, OCaml, ML aren't Python, so you can't copy them,
but sometimes they can teach you how to better program in Python.

>1. The fact that one function calls the other doesn't mean they're "logically nested".<

In this situation they were logically nested, because the scramble_word
is a function needed by another one only, in Java the scramble_word
becomes a (private) method of a text scrambling class; this means it is
nested and hided inside a class. Pascal languages were pre-OOP and they
used nested function for similar purposes, that it to hide and
structure functions inside other ones, that in OO languages like Java,
ObjectPascal, Python, etc. you usually do with classes.

>2. The helper function is useful on its own, so it is a waste to hide it inside another.

Good luck at finding other uses for that function :-)

>3. The nested function makes the enclosing function harder to read.

I can read it fine, but I can understand that you are probably less
used to nested functions, so what's true for me isn't true for you.

>4. I don't buy the namespace pollution argument, we have modules after all.

I presume Guido agrees that function nesting is another way to avoid
namespace pollution :-) There are many ways to do the same thing, to
avoid pollution in one module.

>5. Overhead: every time a new function object is created, for no good reason. (But you save a global name lookup, yet that doesn't appear to weigh up against the function def. [*])<

This function isn't going to be used much. If later I find I have to
optimize it, then I don't use a nested function at all, and I just use
a single function that does everything. But until such optimization
needs, I choose the most logical structuration of the program, that
allows me better programming.

>To me, nested functions (in Python) are *only* helpful when using closures. If you're not using the enclosing scope, you're just obfuscating things.<

Note that until recent time, Python nested scopes were managed quite
differently (in a bad way), and yet, they regarded the function nesting
useful enough to be kept anyway.
I don't agree with you, but every programmer is diffent, because their
story is different. If you have learnt to program with Java/C then you
probably don't like nested functions. If you started with a Pascal-like
language then probably you like that nesting more. If you start with a
Scheme/Lisp background you progrably write Python programs like the
good Norvig:
And so on...

Maybe other people here can say what they think about this topic, it's
just a relaxed discussion.

bear hugs,

More information about the Python-list mailing list