Again: Please hear my plea: print without softspace

[Stephen Horne]

On Fri, 05 Mar 2004 12:35:01 GMT, Dang Griffith
<noemail at noemail4u.com> wrote:

>I understand your idea.  However, the difference between a statement
>and a function is exactly my point, and I see it as relevant--if any
>language change is to come from this discussion.  New functions can be
>added via modules, and do not require changes to the language itself.
>New statements require changes to the language itself, which is what
>the OP is asking for.  
>
>The [in]ability to define "custom shortcuts", with regards to
>statements, is especially relevant because Python doesn't support it.
>Other languages do (Ruby?  et al), so someone thinks it's relevant.
>It's relevant because if Python *did* support it, this thread wouldn't
>be happening.  (Or at least would have ended after someone 
>replied with "oh, just do XYZZY to make a printraw statement".)

OK - sorry I didn't get that.

I suspect that advocating the ability to define custom statements
would be a serious uphill battle. While it allows things to be written
in a different syntax, it doesn't allow for any semantics that aren't
already supportable through functions.

I do see the attraction, though.

I wonder what would be the implications if the brackets for functions
were made optional when the function is used as a statement (in the
sense of not being within an expression, so that the return value will
be discarded). That is...

  printraw (a, b, c, d)         #  'printraw' used as normal function
  print raw (a, b, c, d)        #  'raw' used as normal function


  printraw a, b, c, d           #  legal - brackets optional

  print raw a, b, c, d          #  illegal - brackets required for
                                #  'raw' as it is used in an
                                #  expression

There is the obvious ambiguity - the parser doesn't know whether you
intend a single tuple argument with the no-brackets form or a
conventional list of parameters in brackets. The obvious workaround is
simply to assume a conventional parameter list until proven otherwise,
requiring that when tuple parameters are used the programmer must
resolve the ambiguity (e.g. by reverting back to normal function
syntax). Alternatively, simply ban tuple displays from being used in
bracket-free function calls completely.

Either way, I suspect that there is too much potential for surprises.


-- 
Steve Horne

steve at ninereeds dot fsnet dot co dot uk