pep 8 constants
Eric S. Johansson
esj at harvee.org
Tue Jun 30 17:06:08 CEST 2009
Rhodri James wrote:
> [Trimming for length, sorry if that impacts too much on intelligibility]
no problem, one of the hazards of speech recognition uses you become very verbose.
> 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
> 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.
right. The initial state of a symbol is always a chatty moment. It sets the
context and background information for subsequent use. My initial reaction is
that when you do coffee strength equals five, it would pop up a simple dialog
asking variable or constant? You would say "variable" and it would format
everything the right way. This is a form of interactive dialogue that would be
used consistently throughout the rest of the environment.
> 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.
I don't mind verbal disambiguation if it's infrequent. What I object to is
being forced to disambiguate every time I use a symbol. The reason being is one
is a minor increase in vocal load and can be made a dumb template (maybe) where
is the other is just doing a bunch of makework over and over again.
As for your my class example, you never ever use my_class unless it's prefaced
by an instance of the class MyClass. And if you say something like
My class yields fall class
fall class is my class
fall class = my class
You have sufficient information to know that my class is a class name.and that
you have some number of arguments and the system can run you through a dialogue
to fill in the arguments.
I wish I had the tools to create a simulation of what the editing sequence with
the dialog box pop-ups in nice little animated movie. Heck, if I could just
capture time lapse I could do it with paper and pencil and a voiceover. It would
remind you of Gumby meets South Park but... I digress
> 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
if my template in, you mean a system that can receive type information from
somewhere about every single symbol in the system and then load up a grammar,
handle the dialogs for disambiguation at the same time as providing an editing
environment that lets you refer to symbols by their verbose name instead of
their codename and still operate on. For example, replace an argument should pop
up a dialog box with the second argument of the first method on the line. You
then can change things by their names like second string or array index.
Then sure, maybe a templating system would work. But I don't think it will
thank you for continuing in this dialogue.
More information about the Python-list