[Python-ideas] A suggestion for Python 3 vs Python 2

[Xuancong Wang]

>A few months ago I came up with a working "call statement" implementation
that would allow the parens to be omitted from all simple calls, not just
print: http://bugs.python.org/issue18788

That sounds a great idea which solves a more general problem. But what are
the potential ambiguity issues?
Also, how do you remap ">>fp1" to "file=fp1" as an argument to print()?

Cheers,
Xuancong


On Tue, Nov 12, 2013 at 6:42 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

>
> On 12 Nov 2013 20:15, "Andrew Barnert" <abarnert at yahoo.com> wrote:
> >
> > On Nov 11, 2013, at 19:45, Xuancong Wang <xuancong84 at gmail.com> wrote:
> >
> > > Another suggestion is that 'enumerate' is also frequently used,
> hopefully we can shorten the command as well.
> >
> > One huge advantage of everything being regular functions is that it's
> ridiculously easy to experiment with this. Want to see what it's like to
> use "en" or "ix" or whatever instead of enumerate? Just do "en =
> enumerate", and you can start using it. See how it affects your typing
> speed, and the readability of your code. (Obviously it will make your code
> less readable to the general Python community, but ignore that; the
> interesting question is whether you--or, better, a small group you work
> in--find it readable once you get used to it).
> >
> > Meanwhile, I personally vastly prefer print as a function to a
> statement. I can pass print to a function instead of having to write an
> out-of-line wrapper with def. I can do quick joining without spaces, and
> no-newline-ing without having to mess with magic commas. But then, like
> most of the others who prefer print as a function, I don't actually use it
> nearly as much as the people who are complaining, so maybe that doesn't
> mean much.
>
> A few months ago I came up with a working "call statement" implementation
> that would allow the parens to be omitted from all simple calls, not just
> print: http://bugs.python.org/issue18788
>
> That shows such an approach is technically feasible, but it also makes it
> clear there are major readability issues if the LHS is allowed to be an
> arbitrary expression.
>
> I'm still vaguely curious what a full PEP for 3.5 (with a suitably
> constrained LHS) might look like, but I'm not interested enough to write it
> myself.
>
> Cheers,
> Nick.
>
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20131113/e8f6604b/attachment-0001.html>