Hi all,
I'm not sure whether this idea has been discussed before or not, so I apologize in advanced if that's the case.
Consider the behavior:
f = lambda: True
f.__name__
'<lambda>'
x = f x.__name__
'<lambda>'
I'm arguing the behavior above is too brittle/limited and, considering that the name of the attribute is `__name__`, not entirely consistent with Python's AST. Consider:
f = lambda: True
x = f
At the first line, an ast.Assign would be created whose target is an ast.Name whose `id` is `f`. At the second line, an ast.Assign would be created whose target is an ast.Name whose `id` is `x`. However, as you can see `__name__` special method returns 'lambda' in both cases (just like it was defined https://docs.python.org/3/library/stdtypes.html#definition.__name__), whereas I think either it should have returned '<lambda>' and 'x' or a new function/attribute should exist that does so and more.
For example, consider:
x_1 = 1
x_2 = 1 x_3 = 1 x_4 = x_1 for i in [x_1, x_2, x_3, x_4]: print(i)
1 1 1 1
Now assume such a function exist and is called `name`. Then:
name(1)
'1'
name("Something")
"Something"
name(x_1)
'x_1'
name(x_4)
'x_4'
name(x_5)
'x_5' # Or an Exception!
def itername(collection): for i in map(lambda x: name(x), collection): yield i
for i in [x_1, x_2, x_3, x_4]: print(i, name(i))
1, 'i' 1, 'i' 1, 'i' 1, 'i'
for i in itername([x_1, x_2, x_3, x_4]): print(i)
'x_1' 'x_2' 'x_3' 'x_4'
I think above example gives an idea of the behavior I'm proposing. I can implement it in a hacky way by parsing the block into ast and going through all the nodes that have an `id` or a `name` or `asname` etc, but this behavior wouldn't be pretty for run-time cases e.g. `itername` in the example above.
Anyway I'd appreciate any input.
P.S. I must confess that I can't think of a single case where having this function is the only way to do the job, if the job is sufficiently different from the specification of said function. It'd be only for the sake of convenience, and continuation of what already was there with `__name__`.
On Mon, Jun 19, 2017 at 7:38 AM, Alireza Rafiei alireza.rafiei94@gmail.com wrote:
I'm not sure whether this idea has been discussed before or not, so I apologize in advanced if that's the case.
Consider the behavior:
f = lambda: True f.__name__
'<lambda>'
x = f x.__name__
'<lambda>'
I'm arguing the behavior above is too brittle/limited and, considering that the name of the attribute is `__name__`, not entirely consistent with Python's AST. Consider:
f = lambda: True x = f
At the first line, an ast.Assign would be created whose target is an ast.Name whose `id` is `f`. At the second line, an ast.Assign would be created whose target is an ast.Name whose `id` is `x`.
The __name__ of a function has nothing to do with an Assign node, which is simply assigning a value to something. For instance, if you do:
f = "hello"
you wouldn't expect the string "hello" to have a __name__ - it's just a string. And a lambda function normally won't be assigned to anything. You use lambda when there isn't any name:
do_stuff(lambda q: q * 2 + 1)
and you use def when you want to assign it to a name:
def f(): return True
By the time the Assign operation gets performed, the function object - with all of its attributes, including __name__ - has been completely created. I'm not sure what your proposal would do to these kinds of situations, but it shouldn't be modifying the assigned object.
ChrisA
The __name__ of a function has nothing to do with an Assign node,
which is simply assigning a value to something. For instance, if you do:
f = "hello"
you wouldn't expect the string "hello" to have a __name__ - it's just a string. And a lambda function normally won't be assigned to anything. You use lambda when there isn't any name:
do_stuff(lambda q: q * 2 + 1)
and you use def when you want to assign it to a name:
def f(): return True
By the time the Assign operation gets performed, the function object - with all of its attributes, including __name__ - has been completely created. I'm not sure what your proposal would do to these kinds of situations, but it shouldn't be modifying the assigned object.
I guess I should have framed it as a `quote` for python. You're absolutely right that it shouldn't be modifying the assigned object and it doesn't. I mentioned the Assign to say that in `x = f`, `x` has name as well, however `x.__name__` returns the name of `f` and not `x`.
As for the `f = "hello"`, the value of the name "f" would be "hello" and the value of the name "hello" would be "hello".
My proposal is to either change the behavior of `__name__` or have something similar that acts globally for all objects and types to get a quote-like behavior, provided that the operands of quotes are atomic.
On Sun, Jun 18, 2017 at 2:46 PM, Chris Angelico rosuav@gmail.com wrote:
On Mon, Jun 19, 2017 at 7:38 AM, Alireza Rafiei alireza.rafiei94@gmail.com wrote:
I'm not sure whether this idea has been discussed before or not, so I apologize in advanced if that's the case.
Consider the behavior:
f = lambda: True f.__name__
'<lambda>'
x = f x.__name__
'<lambda>'
I'm arguing the behavior above is too brittle/limited and, considering
that
the name of the attribute is `__name__`, not entirely consistent with Python's AST. Consider:
f = lambda: True x = f
At the first line, an ast.Assign would be created whose target is an ast.Name whose `id` is `f`. At the second line, an ast.Assign would be created whose target is an ast.Name whose `id` is `x`.
The __name__ of a function has nothing to do with an Assign node, which is simply assigning a value to something. For instance, if you do:
f = "hello"
you wouldn't expect the string "hello" to have a __name__ - it's just a string. And a lambda function normally won't be assigned to anything. You use lambda when there isn't any name:
do_stuff(lambda q: q * 2 + 1)
and you use def when you want to assign it to a name:
def f(): return True
By the time the Assign operation gets performed, the function object - with all of its attributes, including __name__ - has been completely created. I'm not sure what your proposal would do to these kinds of situations, but it shouldn't be modifying the assigned object.
ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Mon, Jun 19, 2017 at 8:16 AM, Alireza Rafiei alireza.rafiei94@gmail.com wrote:
I guess I should have framed it as a `quote` for python. You're absolutely right that it shouldn't be modifying the assigned object and it doesn't. I mentioned the Assign to say that in `x = f`, `x` has name as well, however `x.__name__` returns the name of `f` and not `x`.
As for the `f = "hello"`, the value of the name "f" would be "hello" and the value of the name "hello" would be "hello".
My proposal is to either change the behavior of `__name__` or have something similar that acts globally for all objects and types to get a quote-like behavior, provided that the operands of quotes are atomic.
Hmm. So... after x = f, f.__name__ would be different from x.__name__?
ChrisA
On 2017-06-18 22:38, Alireza Rafiei wrote:
Hi all,
I'm not sure whether this idea has been discussed before or not, so I apologize in advanced if that's the case.
Consider the behavior:
>>> f = lambda: True >>> f.__name__ '<lambda>' >>> x = f >>> x.__name__ '<lambda>'I'm arguing the behavior above is too brittle/limited and, considering that the name of the attribute is `__name__`, not entirely consistent with Python's AST. Consider:
>>> f = lambda: True >>> x = fAt the first line, an ast.Assign would be created whose target is an ast.Name whose `id` is `f`. At the second line, an ast.Assign would be created whose target is an ast.Name whose `id` is `x`. However, as you can see `__name__` special method returns 'lambda' in both cases (just like it was defined https://docs.python.org/3/library/stdtypes.html#definition.__name__), whereas I think either it should have returned '<lambda>' and 'x' or a new function/attribute should exist that does so and more.
For example, consider:
>>> x_1 = 1 >>> x_2 = 1 >>> x_3 = 1 >>> x_4 = x_1 >>> for i in [x_1, x_2, x_3, x_4]: >>> print(i) 1 1 1 1Now assume such a function exist and is called `name`. Then:
>>> name(1) '1' >>> name("Something") "Something" >>> name(x_1) 'x_1' >>> name(x_4) 'x_4' >>> name(x_5) 'x_5' # Or an Exception! >>> def itername(collection): >>> for i in map(lambda x: name(x), collection): >>> yield i >>> >>> for i in [x_1, x_2, x_3, x_4]: >>> print(i, name(i)) 1, 'i' 1, 'i' 1, 'i' 1, 'i' >>> for i in itername([x_1, x_2, x_3, x_4]): >>> print(i) 'x_1' 'x_2' 'x_3' 'x_4'
[snip]
That's not correct.
Look at the definition of 'itername'. The lambda returns the result of name(x), which is 'x'.
Therefore, the correct result is:
'x' 'x' 'x' 'x'
[snip] That's not correct. Look at the definition of 'itername'. The lambda returns the result of name(x), which is 'x'. Therefore, the correct result is: 'x' 'x' 'x' 'x'
You're absolutely right! It should be changed to:
def itername(collection):
for i in map(name, collection): yield i
------
Hmm. So... after x = f, f.__name__ would be different from x.__name__?
Yes.
------
I should have written my initial email more carefully! There's another mistake:
However, as you can see `__name__` special method returns 'lambda' in both
cases (just like it was defined https://docs.python.org/3/ library/stdtypes.html#definition.__name__), whereas I think either it should have returned '<lambda>' and 'x' or a new function/attribute should exist that does so and more.
It'd be inconsistent to say x.__name__ should return 'x' and f.__name__ should return '<lambda>'. To avoid further confusion of `name` the function with `__name__`, I take back what I said about `__name__` attribute. However I can't think of an inconsistency with a builtin function called `name` or `quote` or alike that behaves as described previously (name(x) would be 'x' and name(f) would be 'f' and name ("hello") would be "hello" etc.) and still appreciate any input on it.
On Sun, Jun 18, 2017 at 3:24 PM, MRAB python@mrabarnett.plus.com wrote:
On 2017-06-18 22:38, Alireza Rafiei wrote:
Hi all,
I'm not sure whether this idea has been discussed before or not, so I apologize in advanced if that's the case.
Consider the behavior:
>>> f = lambda: True >>> f.__name__ '<lambda>' >>> x = f >>> x.__name__ '<lambda>'I'm arguing the behavior above is too brittle/limited and, considering that the name of the attribute is `__name__`, not entirely consistent with Python's AST. Consider:
>>> f = lambda: True >>> x = fAt the first line, an ast.Assign would be created whose target is an ast.Name whose `id` is `f`. At the second line, an ast.Assign would be created whose target is an ast.Name whose `id` is `x`. However, as you can see `__name__` special method returns 'lambda' in both cases (just like it was defined https://docs.python.org/3/libr ary/stdtypes.html#definition.__name__), whereas I think either it should have returned '<lambda>' and 'x' or a new function/attribute should exist that does so and more.
For example, consider:
>>> x_1 = 1 >>> x_2 = 1 >>> x_3 = 1 >>> x_4 = x_1 >>> for i in [x_1, x_2, x_3, x_4]: >>> print(i) 1 1 1 1Now assume such a function exist and is called `name`. Then:
>>> name(1) '1' >>> name("Something") "Something" >>> name(x_1) 'x_1' >>> name(x_4) 'x_4' >>> name(x_5) 'x_5' # Or an Exception! >>> def itername(collection): >>> for i in map(lambda x: name(x), collection): >>> yield i >>> >>> for i in [x_1, x_2, x_3, x_4]: >>> print(i, name(i)) 1, 'i' 1, 'i' 1, 'i' 1, 'i' >>> for i in itername([x_1, x_2, x_3, x_4]): >>> print(i) 'x_1' 'x_2' 'x_3' 'x_4'[snip]
That's not correct.
Look at the definition of 'itername'. The lambda returns the result of name(x), which is 'x'.
Therefore, the correct result is:
'x' 'x' 'x' 'x'
Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Mon, Jun 19, 2017 at 8:47 AM, Alireza Rafiei alireza.rafiei94@gmail.com wrote:
Hmm. So... after x = f, f.__name__ would be different from x.__name__?
Yes.
There's a couple of major problems with that. The first is that, in Python, there is *absolutely no difference* between accessing an object via one form and via another. For example:
x = object() # or anything else y = [x, x, x] z = x q = {"spam": x} probably = globals()["x"]
You can access y[0], z, q["spam"], and (most likely) probably, and they're all the same thing. Exactly the same object. So there's no way to do attribute access on that object and get different results.
The second problem is that the current behaviour is extremely important. One such place is with function decorators, which frequently need to know the name of the function being worked on:
def command(func): parser.add_parser(func.__name__) ...
@command def spaminate(): ...
Inside the decorator, "func.__name__" has to be the name of the function being decorated ("spaminate"), *not* "func". The function has an identity and a canonical name. Disrupting that would cause major difficulties for these kinds of decorators.
ChrisA
Thanks for the explanation!
On Sun, Jun 18, 2017 at 4:00 PM, Chris Angelico rosuav@gmail.com wrote:
On Mon, Jun 19, 2017 at 8:47 AM, Alireza Rafiei alireza.rafiei94@gmail.com wrote:
Hmm. So... after x = f, f.__name__ would be different from x.__name__?
Yes.
There's a couple of major problems with that. The first is that, in Python, there is *absolutely no difference* between accessing an object via one form and via another. For example:
x = object() # or anything else y = [x, x, x] z = x q = {"spam": x} probably = globals()["x"]
You can access y[0], z, q["spam"], and (most likely) probably, and they're all the same thing. Exactly the same object. So there's no way to do attribute access on that object and get different results.
The second problem is that the current behaviour is extremely important. One such place is with function decorators, which frequently need to know the name of the function being worked on:
def command(func): parser.add_parser(func.__name__) ...
@command def spaminate(): ...
Inside the decorator, "func.__name__" has to be the name of the function being decorated ("spaminate"), *not* "func". The function has an identity and a canonical name. Disrupting that would cause major difficulties for these kinds of decorators.
ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-
Alireza Rafiei -
Chris Angelico -
MRAB