[Python-ideas] Re: [Python-Dev] Re: Inadequate error reporting during function call setup stage

2021-02-22 Thread Paul Sokolovsky
Hello, On Tue, 23 Feb 2021 17:52:20 +1100 Chris Angelico wrote: [] > That's why I dispute that this is an "astonishing oversight". It would > be nice to have the extra information, but given that Python and > Python programmers have survived for thirty years without it, I don't > think it's

[Python-ideas] Re: [Python-Dev] Re: Inadequate error reporting during function call setup stage

2021-02-22 Thread Paul Sokolovsky
Hello, On Tue, 23 Feb 2021 17:52:20 +1100 Chris Angelico wrote: > On Tue, Feb 23, 2021 at 5:33 PM Paul Sokolovsky > wrote: > > Because that's the right analogy of what happens with a function - > > in the function "prolog", there's a series of assignments: > > "formal_paramX = actual_argX".

[Python-ideas] Re: [Python-Dev] Re: Inadequate error reporting during function call setup stage

2021-02-22 Thread Chris Angelico
On Tue, Feb 23, 2021 at 5:33 PM Paul Sokolovsky wrote: > Because that's the right analogy of what happens with a function - in > the function "prolog", there's a series of assignments: > "formal_paramX = actual_argX". Conceptually, those *are* in the > function context (or you would not be able

[Python-ideas] Re: [Python-Dev] Re: Inadequate error reporting during function call setup stage

2021-02-22 Thread Paul Sokolovsky
Hello, On Tue, 23 Feb 2021 12:31:37 +1100 Chris Angelico wrote: > On Tue, Feb 23, 2021 at 10:10 AM Stestagg wrote: > > So Python has identified that a function 'do_thing' is being called > > incorrectly, but /where/ is do_thing defined? This problem gets > > much harder if there are multiple

[Python-ideas] Re: [Python-Dev] Re: Inadequate error reporting during function call setup stage

2021-02-22 Thread Paul Sokolovsky
Hello, On Mon, 22 Feb 2021 17:32:23 -0500 Ned Batchelder wrote: > On 2/22/21 3:06 PM, Paul Sokolovsky wrote: > > > > No, I'm proposing to stop faking lack of the last stack frame due to > > CPython's implementation details. See the original message for more > > info. > > I'm trying to

[Python-ideas] Re: Deprecate/change the behaviour of ~bool

2021-02-22 Thread Marco Sulla
On Tue, 23 Feb 2021 at 02:13, Soni L. wrote: > > Currently ~False is -1 and ~True is -2. Would be nicer if ~bool was the > same as not bool. I suspect this is more for NumPy people. I remember that one of my bosses used `~a` on a bool because he started with NumPy and had a limited knowledge of

[Python-ideas] Re: Deprecate/change the behaviour of ~bool

2021-02-22 Thread Josh Rosenberg
> You could write it as a ^ (not b), as long as you don't mind it giving back an integer rather than a bool. Actually, that'll give back a bool if a is a bool (and (not b) produces a bool); ^ is overridden for bool/bool operations and itself returns a bool. On Tue, Feb 23, 2021 at 1:48 AM Chris

[Python-ideas] Re: Deprecate/change the behaviour of ~bool

2021-02-22 Thread Guido van Rossum
Also, code that is expecting an int should not behave differently when it receives a bool. On Mon, Feb 22, 2021 at 17:47 Chris Angelico wrote: > On Tue, Feb 23, 2021 at 12:14 PM Soni L. wrote: > > > > Currently ~False is -1 and ~True is -2. Would be nicer if ~bool was the > > same as not bool.

[Python-ideas] Re: Deprecate/change the behaviour of ~bool

2021-02-22 Thread Chris Angelico
On Tue, Feb 23, 2021 at 12:14 PM Soni L. wrote: > > Currently ~False is -1 and ~True is -2. Would be nicer if ~bool was the > same as not bool. Hopefully nobody actually relies on this but > nevertheless, it would be a backwards-incompatible change so the whole > deprecation warnings and whatnot

[Python-ideas] Re: [Python-Dev] Re: Inadequate error reporting during function call setup stage

2021-02-22 Thread Chris Angelico
On Tue, Feb 23, 2021 at 10:10 AM Stestagg wrote: > So Python has identified that a function 'do_thing' is being called > incorrectly, but /where/ is do_thing defined? This problem gets much harder > if there are multiple definitions of 'do_thing' in the codebase, as alluded > to in the

[Python-ideas] Deprecate/change the behaviour of ~bool

2021-02-22 Thread Soni L.
Currently ~False is -1 and ~True is -2. Would be nicer if ~bool was the same as not bool. Hopefully nobody actually relies on this but nevertheless, it would be a backwards-incompatible change so the whole deprecation warnings and whatnot would be required. In particular, this is nice for

[Python-ideas] Re: [Python-Dev] Re: Inadequate error reporting during function call setup stage

2021-02-22 Thread Stestagg
To avoid confusion, the traceback below has been updated here with correct names: On Mon, Feb 22, 2021 at 11:07 PM Stestagg wrote: > My take on this is that it's actually a valid suggestion, albeit wrapped > in some unhelpful language. > > This is a more common example, in my opinion: > > ===

[Python-ideas] Re: [Python-Dev] Re: Inadequate error reporting during function call setup stage

2021-02-22 Thread Stestagg
My take on this is that it's actually a valid suggestion, albeit wrapped in some unhelpful language. This is a more common example, in my opinion: === fileA.py === class MyClass: def do_thing(self, arg_a, arg_b): pass === fileB.py === ... class MySubClass(MyClass): pass ===

[Python-ideas] Re: SimpleNamespace vs object

2021-02-22 Thread Mike Miller
On 2021-02-21 20:51, Chris Angelico wrote: In my mind, the current front-runners are: * namespace * ns * thing * mutableobject * mobject * attrobject * bunch Short and PascalCase please, to avoid collisions: * Stuff With credit to George Carlin. ;-) Some of these work as well, Kit is

[Python-ideas] Re: [Python-Dev] Re: Inadequate error reporting during function call setup stage

2021-02-22 Thread Ned Batchelder
On 2/22/21 3:06 PM, Paul Sokolovsky wrote: No, I'm proposing to stop faking lack of the last stack frame due to CPython's implementation details. See the original message for more info. I'm trying to understand what last stack frame (or lack of a last stack frame, or the faking of a lack of

[Python-ideas] Re: Inadequate error reporting during function call setup stage

2021-02-22 Thread Paul Sokolovsky
Hello, On Mon, 22 Feb 2021 19:47:04 + Barry Scott wrote: > > On 22 Feb 2021, at 10:15, Paul Sokolovsky wrote: > > > > It looks like: > > > > Traceback (most recent call last): > > File "pseudoc_tool.py", line 91, in > > File ".../xforms.py", line 25, in print > > TypeError: unexpected

[Python-ideas] Re: Inadequate error reporting during function call setup stage

2021-02-22 Thread Barry Scott
> On 22 Feb 2021, at 10:15, Paul Sokolovsky wrote: > > It looks like: > > Traceback (most recent call last): > File "pseudoc_tool.py", line 91, in > File ".../xforms.py", line 25, in print > TypeError: unexpected keyword argument 'noann' > > - that makes clear that it's "print" function

[Python-ideas] Re: SimpleNamespace vs object

2021-02-22 Thread Steven D'Aprano
On Mon, Feb 22, 2021 at 11:22:09AM +, Rob Cliffe via Python-ideas wrote: > What's wrong with "namespace"?  None of the other names IMO convey the > intended/suggested use nearly as well. The problem with "namespace" is that the intended us is not as a namespace, but as a dict using `.`

[Python-ideas] Re: SimpleNamespace vs object

2021-02-22 Thread Rob Cliffe via Python-ideas
On 22/02/2021 04:51, Chris Angelico wrote: On Mon, Feb 22, 2021 at 1:11 PM Brendan Barnwell wrote: Why not just put SimpleNamespace in the collections module? The one in types could be aliased to it (or vice versa if we really don't want to change anything). That seems like it's

[Python-ideas] Re: Inadequate error reporting during function call setup stage

2021-02-22 Thread Paul Sokolovsky
Hello, On Mon, 22 Feb 2021 10:44:19 +0100 Peter Otten <__pete...@web.de> wrote: > On 21/02/2021 23:06, Terry Reedy wrote: > > On 2/21/2021 12:04 PM, Paul Sokolovsky wrote: > > > >> Traceback (most recent call last): > >>    File "pseudoc_tool.py", line 91, in > >>

[Python-ideas] Re: SimpleNamespace vs object

2021-02-22 Thread Steven D'Aprano
On Mon, Feb 22, 2021 at 06:26:28PM +1100, Chris Angelico wrote: > Ultimately, SimpleNamespace is useless if it can't be found. "Can't" be found is an exaggeration. The std lib is full of little gems, and people learn them and use them. Generally when people talk about something that "can't be

[Python-ideas] Re: Inadequate error reporting during function call setup stage

2021-02-22 Thread Peter Otten
On 21/02/2021 23:06, Terry Reedy wrote: On 2/21/2021 12:04 PM, Paul Sokolovsky wrote: Traceback (most recent call last):    File "pseudoc_tool.py", line 91, in first_class_function_value(func, **pass_params) TypeError: print() got an unexpected keyword argument 'noann' This is not

[Python-ideas] Re: SimpleNamespace vs object

2021-02-22 Thread Steven D'Aprano
On Mon, Feb 22, 2021 at 10:27:55AM +0300, Paul Sokolovsky wrote: > Such short generic names shouldn't be used for types added so late in > the language evolution. Those are names for variables. (And lowercase in > general, with the exception of handful(!) core types). A handful you say. int,