[issue36827] Overriding __new__ method with itself changes behaviour of the class

Alexey Muranov added the comment: I see that I am not the only one who got bitten by this unexpected behaviour (though the others might have not realised it). There is a question ["Creating a singleton in Python"][1] on StackOverflow which was posted in 2011 and by now has the to

[issue36827] Overriding __new__ method with itself changes behaviour of the class

Alexey Muranov added the comment: Here is an example of code where i got surprised by the current behaviour and had to apply some (ugly) workaround: https://gist.github.com/alexeymuranov/04e2807eb5679ac7e36da4454a58fa7e -- ___ Python tracker

[issue32768] object.__new__ does not accept arguments if __bases__ is changed

Alexey Muranov added the comment: There were problems with the use case for mutable bases that i posted (see #36827). Here is an updated version: https://gist.github.com/alexeymuranov/04e2807eb5679ac7e36da4454a58fa7e -- ___ Python tracker

[issue36827] Overriding __new__ method with itself changes behaviour of the class

Alexey Muranov added the comment: I've noticed some faults in my code examples: `super(__class__, __class__)` instead of a more appropriate `super(__class__, cls)`, forgotten `return` before `super(__class__, self).foo(*args, **kwarg)`, maybe there are more. I cannot edit previous comments

[issue36827] Overriding __new__ method with itself changes behaviour of the class

Alexey Muranov added the comment: Incidentally, the documentation gives the following signature of __new__: object.__new__(cls[, ...]) which suggests a variable number of arguments. -- ___ Python tracker <https://bugs.python.org/issue36

[issue36827] Overriding __new__ method with itself changes behaviour of the class

Alexey Muranov added the comment: The issue is the following: i expect overriding a method with itself to not change behaviour of the class. I do not see how my understanding of `__new__` or its point could be relevant. Do we agree that overriding a method with itself should not change

[issue36827] Overriding __new__ method with itself changes behaviour of the class

New submission from Alexey Muranov : I expect that overriding methods with themselves like in the following example should not change the behaviour of the class: class C: a = 1 def __init__(self, b): self.b = b def f(self, x): return x

[issue32768] object.__new__ does not accept arguments if __bases__ is changed

Alexey Muranov added the comment: Here is a use case for writable bases: https://stackoverflow.com/q/56007866 class Stateful: """ Abstract base class for "stateful" classes. Subclasses must implement InitState mixin. """

[issue32768] object.__new__ does not accept arguments if __bases__ is changed

Alexey Muranov added the comment: IMO "overriding" a method with itself should not change the behaviour. So it seems to me that the following is a bug: class C: def __init__(self, m): print(m) class D: @staticmethod

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

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"

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"

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. Both ar

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

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

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

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"

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"

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

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

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

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. --

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

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

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

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

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

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"

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

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

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

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

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

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

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

Re: Problem/bug with class definition inside function definition

rwise, 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, Ale

Re: Problem/bug with class definition inside function definition

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 <alexey.mura...@gmail.com> wrote: I have disc

Problem/bug with class definition inside function definition

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`

On Fri, 2017-11-03 at 22:03 +1100, Chris Angelico wrote: > On Fri, Nov 3, 2017 at 8:48 PM, Alexey Muranov <alexey.muranov@gmail. > com> wrote: > > 'Then' describes what happens next indeed, unless some > > extraordinary > > situation prevents it from happening

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

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,

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

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

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

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

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

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),

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

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

[issue26645] argparse prints help messages to stdout instead of stderr by default

Alexey Muranov added the comment: My grep man page says --help Print a brief help message. but indeed there is no `--help` in usage message. Maybe this is a bug of the man page. Thanks for the explanation. -- ___ Python tracker <

[issue26645] argparse prints help messages to stdout instead of stderr by default

Alexey Muranov added the comment: Thanks for the explanation, this makes sense. I did not notice that argparse outputs to stderr if command line arguments are wrong, i was probably wrong when said it prints error messages to stdout. I did not notice indeed that there were no `-h` option

[issue26645] argparse prints help messages to stdout instead of stderr by default

New submission from Alexey Muranov: I believe that printing help and usage messages to stdout is a design error. In stdout i expect to find the output of my program, not help or diagnostic messages. It is strange to see nothing printed on the screen (where stderr usually goes