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
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".
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
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
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
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
> 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
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.
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
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
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
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:
>
> ===
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
===
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
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
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
> 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
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 `.`
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
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
> >>
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
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
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,
23 matches
Mail list logo