dynamic assigments

[scattered]

On Mar 25, 1:44 am, Steven D'Aprano <steve
+comp.lang.pyt... at pearwood.info> wrote:
>
> In my earlier post, I described the dynamic creation of variables as:
>
> "... something you should *nearly* always avoid doing." [Emphasis added.]
>
> Congratulations, you've found one of the few exceptions. Of course an
> interactive shell must allow you to create variables interactively. It
> would hardly be interactive if you couldn't. This is why interactive
> shells are often called a REPL: Read Eval (or Exec) Print Loop.
>
> Note also that I was describing *variables*. Although there are a lot of
> similarities between variables and instance attributes (so much so that
> some other languages call them both variables), there are some subtle
> differences, and those differences are important. Dynamic *attribute*
> creation is not anywhere near as bad a code-smell as dynamic variables:
>
> setattr(instance, name, value)  # A slight whiff, but usually okay.
>
> globals()[name] = value  # Smells pretty bad, but very occasionally okay.
>
> exec(name + " = " + str(value))  # Reeks like Satan's armpit after a long
> # day mucking out the pits of excrement with the souls of the Damned.
>

I realize that I'm in a distinct minority of Python users, but I tend
to write scripts which consist of nothing but function definitions
intended to be invoked at a REPL. In effect, I used Python as a sort
of highly-programmable calculator. When I saw the OP, it struck me as
something having obvious utility for the sorts of things that I, in
fact, use Python for. I defer to your judgement that such dynamic
bindings are a bad idea in any production code.

> > solving cryptograms (as a matter of fact - I was doing exactly this
> > yesterday in trying to solve some Playfair ciphers).
>
> If you're interested in ciphers, you might find this useful:
>
> http://pypi.python.org/pypi/obfuscate
>

Thanks for the tip

>  You have a
>
> > ciphertext that is a stream of letters in the range A...Z. You need to
> > consult frequencies of letters, pairs of letters, triples of letters,
> > and quadruples of letters that occur. So, you write a script that steps
> > through the cipher text, creates a dictionary which records frequencies
> > of strings of length <= 4, and, as an added convienence, creates
> > bindings of frequencies to these strings.
>
> I don't call that a convenience. I call that a problem. What happens when
> your cipher text includes
>
> "...aBzNk6YPq7psGNQ1Pj?lenprem1zGWdefmspzzQ..."
>
> How many problems can you see there?
>

I specified that the cipher text consists of characters in the range A
to Z (note the case). There is a common convention that, when solving
traditional text-based ciphers, you write the ciphertext in upper case
and the (unkown) plain text in lower case. That way you are dealing
with tentative partial decryptions you can keep track of which letters
in your partial solution are drawn from the original ciphertext and
which are from your guesses

> > Thus - if you want to know how
> > often, say, EFW occurs in the ciphertext you just type EFW (rather than
> > freq["EFW"]) and the Python shell returns the frequency.
>
> Sounds like a terrible idea. What do you do when you want to know how
> often "len" or "1xy" or "???" or "def" occurs?
>
> --
> Steven- Hide quoted text -
>
> - Show quoted text -