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