Hello,
On Fri, 18 Dec 2020 17:42:26 +1300
Greg Ewing wrote:
> On 18/12/20 1:48 pm, Paul Sokolovsky wrote:
> > So, it's already clear that mod.func() syntax will continue to work
> > as before. I don't foresee any problems with implementing that, do
> > you?
>
> What about this:
>
> import ra
On 18/12/20 1:48 pm, Paul Sokolovsky wrote:
So, it's already clear that mod.func() syntax will continue to work as
before. I don't foresee any problems with implementing that, do you?
What about this:
import random
class A:
def choice(self, stuff):
return stuff[0]
a = A()
def f(
Hello,
On Fri, 18 Dec 2020 12:29:10 +1300
Greg Ewing wrote:
> On 18/12/20 7:01 am, Paul Sokolovsky wrote:
> > Now, what if you have an object attribute which stores a callable
> > (no matter is it's bound method, a function, a class, or whatever)?
> >
> > You will need to call it as "(obj.calla
On 18/12/20 7:01 am, Paul Sokolovsky wrote:
Now, what if you have an object attribute which stores a callable (no
matter is it's bound method, a function, a class, or whatever)?
You will need to call it as "(obj.callable_ref)(arg, kw=val)".
So, in strict mode, this:
import random
n = random.c
Hello,
On Thu, 17 Dec 2020 15:28:47 -0500
Alexandre Brault wrote:
> On 2020-12-15 5:16 a.m., Paul Sokolovsky wrote:
> >> The compiler applies it when it
> >> can see the only use of the attribute is an immediately following
> >> call.
> > You're now just a step away from the "right answer". W
On Thu, Dec 17, 2020 at 03:52:51PM +0300, Paul Sokolovsky wrote:
> But I did by now, and you didn't need to wait for me to do it, because
> "(a.b)()" does *exactly* what *you* or anybody else would think it
> does, based on your knowledge of what grouping parens in the
> expressions do. So again,
On 2020-12-15 5:16 a.m., Paul Sokolovsky wrote:
>> The compiler applies it when it
>> can see the only use of the attribute is an immediately following
>> call.
> You're now just a step away from the "right answer". Will you make it?
> I did. And sorry, the whole point of the discussion if to see
On Fri, Dec 18, 2020 at 01:23:34AM +1300, Greg Ewing wrote:
> On 17/12/20 11:25 pm, Paul Sokolovsky wrote:
> >CPython compiles "(a.b)()" using LOAD_METHOD not because it consciously
> >"optimizes" it,
> >but simply because it's *unable* to represent the difference between
> >"a.b()" and "(a.b)()".
17.12.20 21:58, Ethan Furman пише:
> On 12/17/20 11:09 AM, Chris Angelico wrote:
>> "a+b" is NOT implemented as "a.__add__(b)", nor as "type(a).__add__(b)"!
>
> Okay, what is it implemented as?
First, it can use not only method __add__ of the type of a, but also
method __radd__ of the type of b.
On 12/17/20 11:09 AM, Chris Angelico wrote:
> I said I wasn't going to respond, but this one is SUCH a common
> misunderstanding that I don't want people led astray by it.
>
> "a+b" is NOT implemented as "a.__add__(b)", nor as "type(a).__add__(b)"!
Okay, what is it implemented as?
--
~Ethan~
__
Hello,
On Fri, 18 Dec 2020 06:09:56 +1100
Chris Angelico wrote:
> On Fri, Dec 18, 2020 at 5:02 AM Paul Sokolovsky
> wrote:
> > This is not some completely new restriction. For example, following
> > already doesn't work in Python:
> >
> > class A:
> > pass
> >
> > o = A()
> > o.__add__ = la
On Fri, Dec 18, 2020 at 5:02 AM Paul Sokolovsky wrote:
> This is not some completely new restriction. For example, following
> already doesn't work in Python:
>
> class A:
> pass
>
> o = A()
> o.__add__ = lambda self, x: print("me called")
>
> o + A() # lambda above is never called
>
But the
Hello,
On Thu, 17 Dec 2020 10:03:14 +
Stestagg wrote:
[]
> > > > But still, are there Python implementations which compile
> > > > "(a.b)()" faithfully, with its baseline semantic meaning? Of
> > > > course there're.
> > >
> > > OK, Paul, why don't you propose a PR and a bug report about
Hello,
On Fri, 18 Dec 2020 03:05:02 +1300
Greg Ewing wrote:
> On 18/12/20 1:52 am, Paul Sokolovsky wrote:
> > On Fri, 18 Dec 2020 01:23:34 +1300
> > Greg Ewing wrote:
> >> On 17/12/20 11:25 pm, Paul Sokolovsky wrote:
> >>> a) (a.b)() syntax
> >>> b) apply() being resurrected
> >>
> >> I c
On 18/12/20 1:52 am, Paul Sokolovsky wrote:
On Fri, 18 Dec 2020 01:23:34 +1300
Greg Ewing wrote:
On 17/12/20 11:25 pm, Paul Sokolovsky wrote:
a) (a.b)() syntax
b) apply() being resurrected
I can't answer that without knowing what alternative semantics
you have in mind for (a.b)(). You haven'
Hello,
On Fri, 18 Dec 2020 01:23:34 +1300
Greg Ewing wrote:
> On 17/12/20 11:25 pm, Paul Sokolovsky wrote:
> > CPython compiles "(a.b)()" using LOAD_METHOD not because it
> > consciously "optimizes" it, but simply because it's *unable* to
> > represent the difference between "a.b()" and "(a.b)()
On 17/12/20 11:25 pm, Paul Sokolovsky wrote:
CPython compiles "(a.b)()" using LOAD_METHOD not because it consciously
"optimizes" it,
but simply because it's *unable* to represent the difference between
"a.b()" and "(a.b)()".
I'm pretty sure whoever added the optimisation fully intended it
to a
On Wed, Dec 16, 2020 at 10:16:01PM +0300, Paul Sokolovsky wrote:
> With all the above in mind, Python3.7, in a strange twist of fate, and
> without much ado, has acquired a new operator: the method call, ".()".
No it hasn't. That's not a language feature, it is not documented as a
language featu
Hello,
On Thu, 17 Dec 2020 12:46:17 +1300
Greg Ewing wrote:
> On 17/12/20 8:16 am, Paul Sokolovsky wrote:
> > With all the above in mind, Python3.7, in a strange twist of fate,
> > and without much ado, has acquired a new operator: the method call,
> > ".()".
>
> > CPython3.6 and below didn'
On Thu, Dec 17, 2020 at 8:58 AM Paul Sokolovsky wrote:
> Hello,
>
> On Thu, 17 Dec 2020 00:03:51 +0100
> Marco Sulla wrote:
>
> > On Wed, 16 Dec 2020 at 20:18, Paul Sokolovsky
> > wrote:
> > > But still, are there Python implementations which compile "(a.b)()"
> > > faithfully, with its baselin
On 17/12/20 9:56 pm, Paul Sokolovsky wrote:
It's about a new exciting
(hmm, we'll see) feature which, turned out, was there all this time,
... I'm
asking fellow Python programmers if they recognize it. If they do, we
can consider how to get more from that feature,
I don't see how we can get any
Hello,
On Thu, 17 Dec 2020 00:03:51 +0100
Marco Sulla wrote:
> On Wed, 16 Dec 2020 at 20:18, Paul Sokolovsky
> wrote:
> > But still, are there Python implementations which compile "(a.b)()"
> > faithfully, with its baseline semantic meaning? Of course
> > there're.
>
> OK, Paul, why don't yo
On Thu, Dec 17, 2020 at 10:47 AM Greg Ewing wrote:
> A feature of Prothon was that a.b() and t = a.b; t() would do
> quite different things (one would pass a self argument and the
> other wouldn't).
>
> I considered that a bad thing. I *like* the fact that in Python
> I can use a.b to get a bound
On 17/12/20 8:16 am, Paul Sokolovsky wrote:
With all the above in mind, Python3.7, in a strange twist of fate, and
without much ado, has acquired a new operator: the method call, ".()".
> CPython3.6 and below didn't have ".()" operator, and compiled it as
> "attr access" + "function call", but
On Wed, 16 Dec 2020 at 20:18, Paul Sokolovsky wrote:
> But still, are there Python implementations which compile "(a.b)()"
> faithfully, with its baseline semantic meaning? Of course there're.
OK, Paul, why don't you propose a PR and a bug report about it?
Hello,
On Wed, 16 Dec 2020 00:50:27 +1300
Greg Ewing wrote:
> On 16/12/20 12:24 am, Paul Sokolovsky wrote:
>
> > That's good answer, thanks. But... it doesn't correspond to the
> > implementation reality.
>
> Why are we talking about implementation? You said you wanted
> to keep to the conce
Hello,
On Tue, 15 Dec 2020 23:28:53 +1100
Steven D'Aprano wrote:
> On Tue, Dec 15, 2020 at 01:16:21PM +0300, Paul Sokolovsky wrote:
>
> > You're now just a step away from the "right answer". Will you make
> > it? I did.
>
> Sorry Paul, but you didn't.
>
> You fooled yourself by comparing ch
On Tue, 15 Dec 2020 at 17:41, Chris Angelico wrote:
> I learned BOMDAS - Brackets, O (varies in expansion but always minor
> things you don't often see), Multiplication, Division, Addition,
> Subtraction. For some reason it's also written BODMAS, which has the
> exact same meaning (since multiplic
On Tue, Dec 15, 2020 at 04:15:52PM +, David Mertz wrote:
> It feels like a chimp trying to pantomime a philosopher, really. As
> someone with a doctorate in philosophy, I feel triggered :-).
Quoting "A Fish Called Wanda":
Otto: Apes don't read philosophy.
Wanda: Yes they do, Otto, t
I'm going to answer the original question, even though I don't quite
understand it:
> Using explicit parenthesization to convey aspects of semantic meaning?
Absolutely not -- for no other reason that it would break potentially a LOT
of code. If there IS some new useful semantics that could be con
On Wed, Dec 16, 2020 at 3:16 AM David Mertz wrote:
>
> On Tue, Dec 15, 2020 at 11:22 AM Chris Angelico wrote:
>> I'm pretty sure most of us learned *in grade school* about BOMDAS or
>> BODMAS or PEMDAS or whatever mnemonic you pick.
>
> I don't think I ever learned such acronyms! I mean, yes I le
On Tue, Dec 15, 2020 at 11:22 AM Chris Angelico wrote:
> Seriously, are you actually unaware of this fundamental, or are you
> playing dumb to try to make a point? I'm still trying to figure out
> your point here.
I've already put him in my killfile, but probably unwisely, I still see the
follo
On Tue, Dec 15, 2020 at 02:24:48PM +0300, Paul Sokolovsky wrote:
> As I showed right in my first mail, in "a.b()",
> "a.b" doesn't get evaluated at all (since CPython3.7).
`a.b` still has to be looked up, even with the new fast LOAD_METHOD
byte-code. The difference is that it may be able to avoi
On Tue, Dec 15, 2020 at 01:16:21PM +0300, Paul Sokolovsky wrote:
> You're now just a step away from the "right answer". Will you make it?
> I did.
Sorry Paul, but you didn't.
You fooled yourself by comparing chalk and cheese, and imagining that
because you can eat cheese (change the order of op
On Tue, Dec 15, 2020 at 12:49:26PM +0300, Paul Sokolovsky wrote:
> > Are you asking for a semantic difference (the two statements do
> > something different) or an implementation difference (the two
> > statements do the same thing in slightly different ways)?
>
> I'm asking for semantic differe
On 16/12/20 12:24 am, Paul Sokolovsky wrote:
That's good answer, thanks. But... it doesn't correspond to the
implementation reality.
Why are we talking about implementation? You said you wanted
to keep to the conceptual level. At that level, there is NO
difference at all.
--
Greg
On 15/12/20 11:28 pm, Paul Sokolovsky wrote:
that table is not complete. For example, "," (comma) is a
(context-dependent) operator in Python, yet that table doesn't have
explicit entry for it. Unary "*" and "**" are other context-dependent
operators. (Unary "@" too.)
Those things aren't consid
On 15/12/20 11:16 pm, Paul Sokolovsky wrote:
I would suggest us rising up in abstraction level a bit, and
think not in terms of "intermediate variables" but in terms of
"intermediate storage locations".
The fact that it's a *named* intermediate storage location is
important, because it means th
Hello,
On Tue, 15 Dec 2020 23:37:59 +1300
Greg Ewing wrote:
> On 15/12/20 10:04 pm, Paul Sokolovsky wrote:
> > Example 1:
> >
> > a + b + c vs a + (b + c)
> >
> > Question 1:
> > Do you agree that there's a clear difference between left and right
> > expression?
>
> Yes, because the def
On Tue, Dec 15, 2020 at 9:22 PM Paul Sokolovsky wrote:
> On Tue, 15 Dec 2020 20:17:37 +1100
> Chris Angelico wrote:
>
> > On Tue, Dec 15, 2020 at 8:04 PM Paul Sokolovsky
> > wrote:
> > > So, let's try simple yes/no questions:
> > >
> > > Example 1:
> > >
> > > a + b + c vs a + (b + c)
> > >
On 15/12/20 10:49 pm, Paul Sokolovsky wrote:
the question is what semantic (not implementational!) shift
happened in 3.7 (that's the point when it started to be compiled
differently).
There was no semantic shift. The change had *nothing* to do
with semantics. It was *purely* an optimisation.
I
On 15/12/20 10:04 pm, Paul Sokolovsky wrote:
Example 1:
a + b + c vs a + (b + c)
Question 1:
Do you agree that there's a clear difference between left and right
expression?
Yes, because the default order of operations in Python is defined
so that a + b + c is the same as (a + b) + c.
Ex
On 13/12/2020 22:09, Paul Sokolovsky wrote:
Thanks for hanging with me so far, we're getting to the crux of the
question:
Do you think there can be difference between the following two
expressions:
obj.meth()
(obj.meth)()
?
No. The value of an expression in parentheses is the value of the
e
Hello,
On Tue, 15 Dec 2020 20:18:11 +1100
Chris Angelico wrote:
> On Tue, Dec 15, 2020 at 8:08 PM Paul Sokolovsky
> wrote:
> >
> > Hello,
> >
> > On Mon, 14 Dec 2020 02:17:52 -0500
> > David Mertz wrote:
> >
> > > On Sun, Dec 13, 2020, 5:11 PM Paul Sokolovsky d
> > >
> > > > a + b + c vs
Hello,
On Tue, 15 Dec 2020 20:17:37 +1100
Chris Angelico wrote:
> On Tue, Dec 15, 2020 at 8:04 PM Paul Sokolovsky
> wrote:
> > So, let's try simple yes/no questions:
> >
> > Example 1:
> >
> > a + b + c vs a + (b + c)
> >
> > Question 1:
> > Do you agree that there's a clear difference betw
Hello,
On Tue, 15 Dec 2020 08:25:25 +
Jeff Allen wrote:
> On 13/12/2020 22:09, Paul Sokolovsky wrote:
> > Thanks for hanging with me so far, we're getting to the crux of the
> > question:
> >
> > Do you think there can be difference between the following two
> > expressions:
> >
> > obj.meth
On Tue, Dec 15, 2020 at 8:49 PM Paul Sokolovsky wrote:
> Right, and the question is what semantic (not implementational!) shift
> happened in 3.7 (that's the point when it started to be compiled
> differently).
Have you read the release notes?
https://docs.python.org/3/whatsnew/3.7.html#optimiza
On Tue, Dec 15, 2020 at 12:04:44PM +0300, Paul Sokolovsky wrote:
> I certainly agree. But the level at which I'm trying to discuss this
> matter is more "abstract interpretation"'ish. For example, "+" is a
> binary operator, you can't calculate "a + b + c" in one step. There're
> 2 "+", and thus 2
Hello,
On Mon, 14 Dec 2020 19:39:27 +1100
Steven D'Aprano wrote:
> On Mon, Dec 14, 2020 at 01:09:56AM +0300, Paul Sokolovsky wrote:
>
> > Do you think there can be difference between the following two
> > expressions:
> >
> > obj.meth()
> > (obj.meth)()
> >
> > ?
>
> Okay, I'll bite.
>
>
On Tue, Dec 15, 2020 at 8:08 PM Paul Sokolovsky wrote:
>
> Hello,
>
> On Mon, 14 Dec 2020 02:17:52 -0500
> David Mertz wrote:
>
> > On Sun, Dec 13, 2020, 5:11 PM Paul Sokolovsky d
> >
> > > a + b + c vs a + (b + c)
> > >
> > > Here, there's even no guarantee of the same result, if we have use
On Tue, Dec 15, 2020 at 8:04 PM Paul Sokolovsky wrote:
> So, let's try simple yes/no questions:
>
> Example 1:
>
> a + b + c vs a + (b + c)
>
> Question 1:
> Do you agree that there's a clear difference between left and right
> expression? Yes/no.
Yes, there is a difference.
> Example 2:
>
>
Hello,
On Mon, 14 Dec 2020 02:17:52 -0500
David Mertz wrote:
> On Sun, Dec 13, 2020, 5:11 PM Paul Sokolovsky d
>
> > a + b + c vs a + (b + c)
> >
> > Here, there's even no guarantee of the same result, if we have user
> > objects with weirdly overloaded __add__().
> >
>
> 0.1 + 0.2 + 0.3
Hello,
On Mon, 14 Dec 2020 18:05:07 +1100
Chris Angelico wrote:
> On Mon, Dec 14, 2020 at 5:57 PM Paul Sokolovsky
> wrote:
> >
> > But that's what the question was about, and why there was the intro!
> > Let's please go over it again. Do you agree with the following:
> >
> > a + (b + c) <=> t
On Mon, Dec 14, 2020 at 01:09:56AM +0300, Paul Sokolovsky wrote:
> Do you think there can be difference between the following two
> expressions:
>
> obj.meth()
> (obj.meth)()
>
> ?
Okay, I'll bite.
Of course there is a difference: the first statement is ten characters
long, the second is 12 c
On Sun, Dec 13, 2020, 5:11 PM Paul Sokolovsky d
> a + b + c vs a + (b + c)
>
> Here, there's even no guarantee of the same result, if we have user
> objects with weirdly overloaded __add__().
>
0.1 + 0.2 + 0.3 != 0.1 + (0.2 + 0.3)
>
___
Python-idea
On Mon, Dec 14, 2020 at 5:57 PM Paul Sokolovsky wrote:
>
> But that's what the question was about, and why there was the intro!
> Let's please go over it again. Do you agree with the following:
>
> a + (b + c) <=> t = b + c; a + t
>
> ?
>
> Where "<=>" is the equivalence operator. I do hope you
Hello,
On Mon, 14 Dec 2020 09:37:42 +1100
Chris Angelico wrote:
> > 2 8 LOAD_NAME0 (obj)
> > 10 LOAD_METHOD 1 (meth)
...
> >
> > 3 16 LOAD_NAME0 (obj)
> > 18 LOAD_ATTR1 (meth)
...
> Cre
On Mon, Dec 14, 2020 at 9:11 AM Paul Sokolovsky wrote:
> What would be the explanation for all that?
>
>
> For reference, the disassembly of the 3 lines with CPython3.7 is
> provided:
>
> 1 0 LOAD_NAME0 (obj)
> 2 LOAD_METHOD 1 (meth)
>
58 matches
Mail list logo
