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
<alexey.mura...@gmail.com>
wrote:
> On Mon, Apr 1, 2019 at 3:52 PM Alexey Muranov <alexey.muranov at
> 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 are constructs of syntactic magic that aid
> readability at
> a high level but potentially obscure the details of execution (in
> relatively unimportant ways) when examined at a low level.
Since i understand that the "super() magic" is just evaluation in a
predefined environment, it does not look so very magic.
It's the reason why this doesn't work:
superduper = super
class A:
def f(self):
return 42
class B(A):
def f(self):
return superduper().f()
B().f()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in f
RuntimeError: super(): __class__ cell not found
But this does:
class C(A):
def f(self):
return superduper().f()
not super
C().f()
42
I don't know, seems magical to me.
Moreover, without this "magic", `super()` would have just produced
an
error. So this magic did not change behaviour of something that
worked
before, it made "magically" work something that did not work before
(but i am still not excited about it).
I'm curious how you feel about this example then (from the CPython
3.7.2
REPL; results from different Python implementations or from scripts
that
comprise a single compilation unit may vary)?
372 is 372
True
b = 372; b is 372
True
b = 372
b is 372
False
> Maybe it was from my talk of implementing this by replacing the
> assignment
> with an equivalent def statement in the AST. Bear in mind that
the def
> statement is already just a particular kind of assignment: it
creates
> a
> function and assigns it to a name. The only difference between the
> original
> assignment and the def statement that replaces it is in the
__name__
> attribute of the function object that gets created. The proposal
just
> makes
> the direct lambda assignment and the def "assignment" to be fully
> equivalent.
`def` is not an assignment, it is more than that.
def is an assignment where the target is constrained to a single
variable
and the expression is constrained to a newly created function object
(optionally "decorated" first with one or more composed function
calls).
The only ways in which:
@decorate
def foo(blah):
return stuff
is more than:
foo = decorate(lambda blah: stuff)
are: 1) the former syntactically allows statements inside the function
body, not just expressions; 2) the former syntactically allows
annotations
on the function; and 3) the former syntactically sets a function name
and
the latter doesn't. In other words, all of the differences ultimately
boil
down to syntax.
Sorry, i do not feel like continuing this discussion for much longer,
or we need to concentrate on some specific statement on which we
disagree.
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 was talking about the normal assignment by which
anyone can bind any value to any variable.
2. If i execute an assignment statement
foo = ...
and instead of evaluating the right-hand side and assigning the
value to "foo" variable Python does something else, i consider the
assignment operation (<var> = <expr>) broken, as it does not do
assignment (and only assignment). I've said more on this in previous
messages.
3. About the examples with `372 is 372`, Python gives no garanties
about the id's of numerical objects, and about id's of many other types
of immutable objects. The user is not supposed to rely on their
equality or inequality.
Anytime Python's interpreter encounter two immutable objects that
it finds identical, it is free to allocate a single object for both,
this does not change the guaranteed semantics of the program.
The '__name__' attribute of an object, as well as most (or all)
other attributes, is a part of object's value/contents, no analogies
with the id's.
I am sorry, but except maybe for one or two more very specific
questions, I am probably not going to continue.
Alexey.
--
https://mail.python.org/mailman/listinfo/python-list
