Re: Syntax for one-line "nonymous" functions in "declaration style"

2019-04-03 Thread Alexey Muranov
On mer., Apr 3, 2019 at 6:00 PM, python-list-requ...@python.org wrote: On Wed, Apr 3, 2019 at 3:55 AM Alexey Muranov wrote: I clarified what i meant by an assignment, and i believe it to be a usual meaning. 1. `def` is not an assignment, there is no left-hand side or right-hand side. I

Re: Syntax for one-line "nonymous" functions in "declaration style"

2019-04-02 Thread Alexey Muranov
On mar., Apr 2, 2019 at 6:00 PM, python-list-requ...@python.org wrote: On Tue, Apr 2, 2019 at 1:43 AM Alexey Muranov wrote: > On Mon, Apr 1, 2019 at 3:52 PM Alexey Muranov gmail.com> > wrote: > > > > I only see a superficial analogy with `super()`, but perhaps it

Re: Syntax for one-line "nonymous" functions in "declaration style"

2019-04-02 Thread Alexey Muranov
On Mon, Apr 1, 2019 at 3:52 PM Alexey Muranov gmail.com> wrote: > > I only see a superficial analogy with `super()`, but perhaps it is > because you did not give much details of you suggestion. No, it's because the analogy was not meant to be anything more than superficial. Bo

Generator definition syntax (was: Syntax for one-line "nonymous" functions)

2019-04-02 Thread Alexey Muranov
On mar., Apr 2, 2019 at 4:31 AM, python-list-requ...@python.org wrote: Re: ">> Neither i like how a function magically turns into a generator if the keyword `yield` appears somewhere within its definition. I agree, there should have been a required syntactic element on the "def" line as we

Re: Syntax for one-line "nonymous" functions in "declaration style"

2019-04-01 Thread Alexey Muranov
On lun., avril 1, 2019 at 6:00 PM, python-list-requ...@python.org wrote: On Sun, Mar 31, 2019 at 1:09 PM Alexey Muranov wrote: On dim., Mar 31, 2019 at 6:00 PM, python-list-requ...@python.org wrote: > On Sat, Mar 30, 2019, 5:32 AM Alexey Muranov > > wrote: > >> &

Re: Syntax for one-line "nonymous" functions in "declaration style"

2019-03-31 Thread Alexey Muranov
On dim., Mar 31, 2019 at 6:00 PM, python-list-requ...@python.org wrote: On Sat, Mar 30, 2019, 5:32 AM Alexey Muranov wrote: On ven., Mar 29, 2019 at 4:51 PM, python-list-requ...@python.org wrote: > > There could perhaps be a special case for lambda expressions such > that

Re: Syntax for one-line "nonymous" functions in "declaration style"

2019-03-30 Thread Alexey Muranov
On ven., Mar 29, 2019 at 4:51 PM, python-list-requ...@python.org wrote: On Thu, Mar 28, 2019 at 2:30 PM Alexey Muranov  wrote: On jeu., mars 28, 2019 at 8:57 PM, Terry Reedy wrote: > Throwing the name away is foolish. Testing functions is another > situation in which fu

Re: Python-list Digest, Vol 186, Issue 31

2019-03-30 Thread Alexey Muranov
On ven., Mar 29, 2019 at 4:51 PM, python-list-requ...@python.org wrote: On Thu, Mar 28, 2019 at 2:30 PM Alexey Muranov wrote: On jeu., mars 28, 2019 at 8:57 PM, Terry Reedy wrote: > Throwing the name away is foolish. Testing functions is another > situation in which function nam

Re: Syntax for one-line "nonymous" functions in "declaration style"

2019-03-28 Thread Alexey Muranov
On jeu., mars 28, 2019 at 5:00 PM, python-list-requ...@python.org wrote: So documentation of that syntax would 100% be required Regarding documentation, i believe there would be 3 line to add: () = is a syntactic sugar for = lambda : Alexey. -- https://mail.python.org/mailman

Re: Syntax for one-line "nonymous" functions in "declaration style"

2019-03-28 Thread Alexey Muranov
On jeu., mars 28, 2019 at 8:57 PM, Terry Reedy wrote: On 3/28/2019 12:29 PM, Alexey Muranov wrote: On jeu., Mar 28, 2019 at 5:00 PM, python-list-requ...@python.org wrote: So my opinion is that lambda expressions should only be used within larger expressions and never directly bound. It

Re: Syntax for one-line "nonymous" functions in "declaration style"

2019-03-28 Thread Alexey Muranov
On jeu., mars 28, 2019 at 8:57 PM, Terry Reedy wrote: But i see your point about never assigning lambdas directly, it makes sense. But sometimes i do assign short lambdas directly to variable. Is the convenience and (very low) frequency of applicability worth the inconvenience of confu

Re: Syntax for one-line "nonymous" functions in "declaration style"

2019-03-28 Thread Alexey Muranov
On jeu., mars 28, 2019 at 5:00 PM, python-list-requ...@python.org wrote: On 2019-03-27 10:42 a.m., Paul Moore wrote: On Wed, 27 Mar 2019 at 12:27, Alexey Muranov wrote: On mer., mars 27, 2019 at 10:10 AM, Paul Moore wrote: On Wed, 27 Mar 2019 at 08:25, Alexey Muranov wrote: Whey

Re: Syntax for one-line "nonymous" functions in "declaration style"

2019-03-28 Thread Alexey Muranov
On jeu., Mar 28, 2019 at 5:00 PM, python-list-requ...@python.org wrote: So my opinion is that lambda expressions should only be used within larger expressions and never directly bound. It would be however more convenient to be able to write instead just f(x) = x*x Given my view above,

Re: Syntax for one-line "nonymous" functions in "declaration style"

2019-03-27 Thread Alexey Muranov
On mer., Mar 27, 2019 at 5:00 PM, python-list-requ...@python.org wrote: On 27/03/19 09:21, Alexey Muranov wrote: Whey you need a simple function in Python, there is a choice between a normal function declaration and an assignment of a anonymous function (defined by a lambda-expression) to

Re: Syntax for one-line "nonymous" functions in "declaration style"

2019-03-27 Thread Alexey Muranov
On mer., mars 27, 2019 at 10:10 AM, Paul Moore wrote: On Wed, 27 Mar 2019 at 08:25, Alexey Muranov wrote: Whey you need a simple function in Python, there is a choice between a normal function declaration and an assignment of a anonymous function (defined by a lambda-expression) to

Syntax for one-line "nonymous" functions in "declaration style"

2019-03-27 Thread Alexey Muranov
Whey you need a simple function in Python, there is a choice between a normal function declaration and an assignment of a anonymous function (defined by a lambda-expression) to a variable: def f(x): return x*x or f = lambda x: x*x It would be however more convenient to be able to write

Re: Problem/bug with class definition inside function definition

2018-05-08 Thread Alexey Muranov
e, probably the solution with def f(a): _a = a class D: a = _a return D is good enough, if Python does not allow to refer "simultaneously" to variables from different scopes if they have the same name. Alexey. On Tue, 8 May, 2018 at 12:21 AM, Alexe

Re: Problem/bug with class definition inside function definition

2018-05-07 Thread Alexey Muranov
To be more exact, i do see a few workarounds, for example: def f4(a): b = a class D: a = b # Works return D But this is not what i was hoping for. Alexey. On Tue, 8 May, 2018 at 12:02 AM, Alexey Muranov wrote: I have discovered the following bug or

Problem/bug with class definition inside function definition

2018-05-07 Thread Alexey Muranov
I have discovered the following bug or problem: it looks like i am forced to choose different names for class attributes and function arguments, and i see no workaround. Am i missing some special syntax feature ? Alexey. --- x = 42 class C1: y = x # Works class C2: x = x # Works #

Re: replacing `else` with `then` in `for` and `try`

2017-11-03 Thread Alexey Muranov
On Fri, 2017-11-03 at 22:03 +1100, Chris Angelico wrote: > On Fri, Nov 3, 2017 at 8:48 PM, Alexey Muranov com> wrote: > > 'Then' describes what happens next indeed, unless some > > extraordinary > > situation prevents it from happening, for example: > > &

Re: replacing `else` with `then` in `for` and `try`

2017-11-03 Thread Alexey Muranov
On Thu, 2017-11-02 at 16:31 +, Jon Ribbens wrote: > On 2017-11-02, Steve D'Aprano wrote: > > On Fri, 3 Nov 2017 12:39 am, Jon Ribbens wrote: > > > Why would we want to make the language worse? It is fairly > > > obvious > > > what 'else' means, > > > > Yes, obvious and WRONG. > > Nope, o

Re: replacing `else` with `then` in `for` and `try`

2017-11-02 Thread Alexey Muranov
On Thu, 2017-11-02 at 08:21 +1100, Chris Angelico wrote: > > With try/except/else, it's "do this, and if an exception happens, do this, else do this". So else makes perfect sense. Indeed, i forgot about `except`. I agree that "try/then/except/finally" would be better than "try/except/then/f

Re: replacing `else` with `then` in `for` and `try`

2017-11-02 Thread Alexey Muranov
On Wed, 2017-11-01 at 21:30 +, Stefan Ram wrote: > > In languages like Algol 68, »then« is used for a clause > that is to be executed when the main condition of an > if-statement /is/ true, so this might cause some confusion. > sure, and `else` is used for a clause that is to be execu

Re: replacing `else` with `then` in `for` and `try`

2017-11-02 Thread Alexey Muranov
On Thu, 2017-11-02 at 08:29 +1100, Chris Angelico wrote: > On Thu, Nov 2, 2017 at 8:23 AM, Ned Batchelder > > wrote: > > > > > > Apart from the questions of backward compatibility etc (Python is > > unlikely > > to ever go through another shift like the 2/3 breakage), are you > > sure "then" >

replacing `else` with `then` in `for` and `try`

2017-11-01 Thread Alexey Muranov
Hello, what do you think about the idea of replacing "`else`" with "`then`" in the contexts of `for` and `try`? It seems clear that it should be rather "then" than "else." Compare also "try ... then ... finally" with "try ... else ... finally". Currently, with "else", it is almost impossib