Call for signatories for J2
Tim Hochberg
tim.hochberg at ieee.org
Thu Aug 26 14:15:38 EDT 2004
Doug Holton wrote:
> Tim Hochberg wrote:
>
>> I also have a weak preference for 'per' over 'using', FWIW. The
>> shortness of 'per' is one virtue. Another is that, because it's
>> slightly obscure, it may be easier to indoctrinate users that
>> 'per...def' is the correct order, not 'def...per'. For me at least
>> it's 'obvious' that if 'using...def' works then so should
>> 'def...using', which of course it can't. The order is amenable to
>> memorization, but I still anticipate more thinkos of this type from
>> using than from per. On the downside, per may be extremely obscure to
>> those that are neither native speakers of English or one of the
>> romance languages.
>
>
> Even in common English usage, "per" usually comes in the middle of a
> phrase, not the beginning, like "miles per hour" or "Changes were made
> to the manuscript per the author's instructions" (people would more
> commonly use the phrase "according to" rather than "per" there).
Per the author's instructions, changes were made.
Changes were made per the author's instructions.
Using only hand tools, we built the treehouse.
We built the treehouse using only hand tools.
Both of 'per' and 'using' (and most of the other keyword options that
aren't really horrible) have a bias for being read backwards. My
contention was that since 'per' is probably a bit less familiar it would
be easier to beat the nonstandard order into ones head.
> None of those uses bare any resemblance to how decorators affect
> functions.
I don't agree. Or at least I don't agree that:
per:
instructions
def func():
...
Is any worse a model for what's going on than:
using:
functions
def func():
...
Neither's great, both are suggestive of what's going on. Unless we use:
use_the_following_functions_to_transform_the_subsequent_def
It's going to be pretty hard to get something that's much more than
suggestive.
> "per:" by itself on a line is pretty much meaningless.
> Looks more like you misspelled pre.
If "pre:" was legal Python, I certainly wouldn't support 'per:'. While
'per' may in fact be too obscure, and that's legitimate point to argue,
I'm not sure that arguing about how it reads out of context is all that
relevant. Whatever keyword is chosen, I expect it to be fairly close to
the subsequent def.
> If people are liking Latin keywords for decorators now, why not "sic"?
It's even vauger than per. I'll give it that. When I was young, I was
too lazy to look it up, so I backronymed this into Spelling
Intentionally Compromised. In retrospect, this probably fits the real
usage better than the Latin, so no harm done.
-rim
More information about the Python-list
mailing list