pep 8 constants

[Rhodri James]

[Trimming for length, sorry if that impacts too much on intelligibility]

On Tue, 30 Jun 2009 02:52:37 +0100, Eric S. Johansson <esj at harvee.org>  
wrote:

> let's use an example. Admittedly, this is a very simple example but  
> hopefully it
> illustrates my point
>
> What I dictate is:
>
> from pots is class telephone
>
> What should generate is:
>
> class Telephone (pots):
>
> as you can see, taken from the simplistic expression, we generate the  
> right
> pep-8 convention. (I think). This is not the only grammar one can use  
> but, it's
> one that comes to mind that doesn't have a lot of dead ends.

[snip fuller example]

> at each stage of the way, names get transformed into the pep-8 form  
> without me
> having to say anything special. The environment knows what form it wants  
> and
> does the transformation automatically.  I'm surprised people aren't  
> doing this
> already for their handcrafted code. It's one less bit of detail you need  
> to pay
> attention to.

This goes a long way, but it doesn't eliminate the need for some forms
of escape coming up on a moderately frequent basis.  Consider "Coffee
strength equals five" for example: this could mean either

   coffee_strength = 5

or

   COFFEE_STRENGTH = 5

depending on whether we will later be using it as a constant or not.
Python doesn't have syntactic constants, which is precisely why PEP-8
is useful.  You might have enough smarts in your system for it to
remember after the first time you use "coffee strength", and it might
be unambiguous, but at the very least you need to be able to say
"Constant coffee strength equals five" first time round.

This isn't the only occasion when you simply don't have the context
to avoid verbal disambiguation.  Are you accessing attributes of the
class MyClass or its instance my_class, for instance?  In your initial
post you seemed to be claiming that having to do this disambiguation
textually was bad, and PEP-8 should therefore be rejected.  Given
that I'm not prepared to lose the productivity increase that comes
with being able to disambiguate visually at a glance, I don't see
that it's avoidable.

Incidentally, since what you're proposing is essentially templating,
wouldn't it be better to do it as post-processing on the speech
recognition rather than building it directly into an editor?
to resolve

-- 
Rhodri James *-* Wildebeest Herder to the Masses