Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #32307

Re: attaching names to subexpressions

References <a533d812-480e-479b-9210-7097c2d70d73@a4g2000pbo.googlegroups.com> <mailman.2934.1351343030.27098.python-list@python.org> <508c810f$0$29967$c3e8da3$5496439d@news.astraweb.com> <mailman.2950.1351403908.27098.python-list@python.org> <508cd7e7$0$29967$c3e8da3$5496439d@news.astraweb.com>
From Devin Jeanpierre <jeanpierreda@gmail.com>
Date 2012-10-28 04:12 -0400
Subject Re: attaching names to subexpressions
Newsgroups comp.lang.python
Message-ID <mailman.2954.1351411980.27098.python-list@python.org> (permalink)

Show all headers | View raw


On Sun, Oct 28, 2012 at 2:59 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sun, 28 Oct 2012 01:57:45 -0400, Devin Jeanpierre wrote:
>
>> We have a problem, and two solutions. Solution 1 has downside A, and
>> solution 2 has downside B. If he complains about downside A, you say,
>> well, use solution 2. If he complains about downside B, you say, well,
>> use solution 1.
>>
>> What if he wants to avoid both downsides A and B? What solution does he
>> use then?
>
> "I want to have my cake, and eat it too." Every solution has some
> downside.

And yet you claimed all of their problems could be solved, without
adding any new syntax, "trivially".

Perhaps what you meant is that it's trivial to ignore their concerns
and use existing syntax.

> Just because no other solution is perfect (whatever that
> means!) doesn't mean we must keep adding more and more ways to solve the
> same problem into a language.

A fair point.

> The proposed solution, assignment as an expression, has multiple
> downsides:

Almost all of your "downsides" are nonspecific costs to implementing
new features. Which is to say, you can't think of any downside to this
approach at all, other than it being "open to abuse".

On the other hand, it'd probably be pretty useless if it weren't. :)

> All these downsides make the barrier to entry for new syntax very high.
> Python is a 20 year old mature language. Most, perhaps all, of the low-
> hanging fruit syntax-wise has been picked.

Absolutely. Especially considering that this is a "small" and obvious
change to Python, I hope nobody is holding their breath for this to be
added.

> Don't be surprised when
> there is opposition to adding new syntax. With very few exceptions, new
> syntax has real costs and little or questionable benefit.

Surprised? I think you've given me this speech twice now.

-- Devin

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

attaching names to subexpressions Steve Howell <showell30@yahoo.com> - 2012-10-26 19:42 -0700
  Re: attaching names to subexpressions Gelonida N <gelonida@gmail.com> - 2012-10-27 15:03 +0200
    Re: attaching names to subexpressions Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-28 00:49 +0000
      Re: attaching names to subexpressions rusi <rustompmody@gmail.com> - 2012-10-27 18:57 -0700
      Re: attaching names to subexpressions Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-10-28 01:57 -0400
        Re: attaching names to subexpressions Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-28 06:59 +0000
          Re: attaching names to subexpressions Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-10-28 04:12 -0400
        Re: attaching names to subexpressions Neil Cerutti <neilc@norwich.edu> - 2012-10-29 11:53 +0000
      Re: attaching names to subexpressions Chris Angelico <rosuav@gmail.com> - 2012-10-28 17:01 +1100
      Re: attaching names to subexpressions "F.R." <anthra.norell@bluewin.ch> - 2012-10-28 08:12 +0100
      Re: attaching names to subexpressions Chris Angelico <rosuav@gmail.com> - 2012-10-28 21:44 +1100

csiph-web