The problem with "as" [was "Re: PEP 318"]

[Stephen Horne]

On Thu, 25 Mar 2004 13:48:24 -0700, David MacQuigg <dmq at gain.com>
wrote:

>[David MacQuigg]:
>Using a symbol to introduce an extension doesn't mean we can't add
>more extensions later.  If we extend the def statement now with
>$(staticmethod)

Ah - I see what you mean.

I'm not sure I'm convinced, but I get how this has better
compatibility (the name need not be a keyword or pseudo-keyword, for
instance, and cannot conflict with user identifiers).

>[Stephen Horne]:
>>What I might use is something like...
>>
>>  pragma printoptions ( separator = ' ', terminator = '\n' ) :
>>    print "whatever"
>>    print "something else"
>>
>>...as a general way of providing standard-behaviour-overriding flags
>>for built-ins.
>
>[David MacQuigg]:
>I like this.  It keeps the basic syntax of the print statement clean.
>It avoids a lot of typing in situations where there is a repetition of
>the same 'decoration' on many statemtents.  The main drawback I see is
>that in many situations, the modifcation is 'one time only'.  Then we
>have *three* statements instead of one. ( We need a statement to
>restore the default printoptions.)

No, we need two statements. There is no need to restore the default
printoptions - only to dedent out of the block where the non-default
printoptions are set. The implementation would have printoptions in a
stack structure, so the most recent override can always be easily
referenced.

The two-line format for isolated prints needing non-default options
isn't too bad as it would be a struggle to keep such print statements
on one line in practical cases anyway.

The biggest problem would be the case where there are prints dotted
throughout the code which all use the same nondefault options. And
even then, you could probably use something like...

  pragma printoptions ( separator = ' ', terminator = '\n' ) :
    main_program_call ()

>Using the "common-symbol-for-a statement-extension" syntax, we could
>modify multiple statements without too much clutter using something
>like:
>
>opts = printoptions( separator = ' ', terminator = '\n' )
>print @(opts) "whatever"
>print @(opts) "something else"

OK - this certainly has advantages. But it assumes that the only way
to extend a print statement would be to accept some kind of attributes
from a specified object.

If you're really doing named extensions, that should be...

  opts = printoptions( separator = ' ', terminator = '\n' )
  print @(printoptions: opts) "whatever"

Otherwise, your standard extensions symbol isn't standard - it is used
to do different things in different contexts, as its use to apply
decorators in def is fundamentally different to its use to apply
printoptions in print.

Alternately, instead of allowing your symbol to handle any new
extension syntax, it could just handle one syntax - applying
nonstandard options. In this case, the decorators example might become
something like...

  def name (args) @{ "decorators" : [deco1, deco2, deco3]} :
    pass

Or, for convenience...

  opts = { "decorators" : [deco1, deco2, deco3]}

  def name (args) @opts :
    pass

Actually, I quite like this. I suspect that pretty much any extension
to a statement could be handled using a set of named options stored in
a dictionary.


>[David MacQuigg]:
>>>I guess I'll need an example here.  Seems like the potential for
>>>future incompatibilities is *greater* if the syntax itself has
>>>"special meaning" ( e.g. "decorators" instead of [] ).
>
>[Stephen Horne]:
>>If a statement has a 'decorators' extension syntax, it can always add
>>a 'widget' or 'blodget' extension syntax later, being clear to both
>>the parser and the reader.
>
>[David MacQuigg]:
>So to make the example more concrete, I assume you would do something
>like:
>
>def func1( x, y, z ) decorators(staticmethod), blodgett(gradoo):
>
>instead of:
>
>def func1( x, y, z ) [staticmethod, gradoo]:

No, if 'gradoo' is a kind of decorator I'd do something like...

  def func1( x, y, z ) decorators(staticmethod, gradoo) :

And you'd presumably do something like...

  def func1( x, y, z ) $(decorators: staticmethod, gradoo) :

But I thought you were suggesting something like...

  def func1( x, y, z ) $ staticmethod, gradoo :

Looking back I think I just missed where you said your standard symbol
syntax would also name the extension. Then, taking the paragraph...

>[David MacQuigg]:
>>>I guess I'll need an example here.  Seems like the potential for
>>>future incompatibilities is *greater* if the syntax itself has
>>>"special meaning" ( e.g. "decorators" instead of [] ).

I was thrown by the "I guess I'll need an example here" with no
apparant example given, and by the "... if the syntax itself has
"special meaning"", which I took to mean you thought I shouldn't have
a name (ie shouldn't specify the special meaning) though now I see
that your suggestion names the extension too.

I'm still scratching my head a little, but at least now I know that I
was confused ;-)


-- 
Steve Horne

steve at ninereeds dot fsnet dot co dot uk