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


Groups > comp.lang.python > #85587

Re: Alternative to multi-line lambdas: Assign-anywhere def statements

References (3 earlier) <mailman.18121.1422151185.18130.python-list@python.org> <54db5356$0$3915$e4fe514c@dreader34.news.xs4all.nl> <mbh1r8$3eb$1@ger.gmane.org> <CALwzidkQ4uoya63r6ugeTnG3egJHL0XbUQFLK1iQFZGVJNgyYg@mail.gmail.com> <CAPTjJmoyKUzXTYBBiySdvijfhqsExkkBwfnhFFk12A0cLOmCgw@mail.gmail.com>
From Ian Kelly <ian.g.kelly@gmail.com>
Date 2015-02-12 09:17 -0700
Subject Re: Alternative to multi-line lambdas: Assign-anywhere def statements
Newsgroups comp.lang.python
Message-ID <mailman.18692.1423757888.18130.python-list@python.org> (permalink)

Show all headers | View raw


On Wed, Feb 11, 2015 at 8:56 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Thu, Feb 12, 2015 at 1:57 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> The reason I don't like this replacing def isn't because the name is
>> necessarily lost. It's because the lack of the well-defined def
>> statement encourages more complex usages like
>>
>>     functions['f'] = x -> x**2
>>
>> where such implicit transformations won't work.
>
> That's actually where this started. I mean, if a function can be
> called "<lambda>", why can't it be called "functions['f']"?

If the name isn't an identifier then it will make it harder to look up
the function from the name via introspection. Another thing that might
cause problems is decoration:

    say_hello = classmethod(cls -> print("Hello from %s" % cls.__name__))

How would the name say_hello make it all the way onto the function
object here? I suppose there could be a syntax like:

    @classmethod
    say_hello = cls -> print("Hello from %s" % cls.__name__)

But now the assignment statement has to be treated grammatically as a
special form of assignment, just like a def statement.

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


Thread

Re: Alternative to multi-line lambdas: Assign-anywhere def statements Ethan Furman <ethan@stoneleaf.us> - 2015-01-24 17:58 -0800
  Re: Alternative to multi-line lambdas: Assign-anywhere def statements Yawar Amin <yawar.amin@gmail.com> - 2015-01-24 18:30 -0800
    Re: Alternative to multi-line lambdas: Assign-anywhere def statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-25 15:27 +1100
      Re: Alternative to multi-line lambdas: Assign-anywhere def statements Yawar Amin <yawar.amin@gmail.com> - 2015-01-25 17:26 -0800
        Re: Alternative to multi-line lambdas: Assign-anywhere def statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-26 13:46 +1100
  Re: Alternative to multi-line lambdas: Assign-anywhere def statements albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-02-11 13:04 +0000
    Re: Alternative to multi-line lambdas: Assign-anywhere def statements Clarence <clarence1126@gmail.com> - 2015-02-11 06:28 -0800
    Re: Alternative to multi-line lambdas: Assign-anywhere def statements Ethan Furman <ethan@stoneleaf.us> - 2015-02-11 08:52 -0800
    Re: Alternative to multi-line lambdas: Assign-anywhere def statements Terry Reedy <tjreedy@udel.edu> - 2015-02-11 21:06 -0500
    Re: Alternative to multi-line lambdas: Assign-anywhere def statements Ian Kelly <ian.g.kelly@gmail.com> - 2015-02-11 19:57 -0700
    Re: Alternative to multi-line lambdas: Assign-anywhere def statements Chris Angelico <rosuav@gmail.com> - 2015-02-12 14:56 +1100
    Re: Alternative to multi-line lambdas: Assign-anywhere def statements Ian Kelly <ian.g.kelly@gmail.com> - 2015-02-12 09:17 -0700

csiph-web