Why do function definitions require parens?
class MyClass: ... pass ... def my_func: File "<stdin>", line 1 def my_func: ^ SyntaxError: invalid syntax
This seems to me to break a symmetry with class definitions. I assume this is just a hold off from C, perhaps there is a non-historical reason tho. I believe in the past we've forced parens in list comprehensions to create a symmetry between comprehensions/generator expressions. Why not for this?
Just to be clear, I wasn't suggesting forcing parens for class definitions. Rather make them optional for functions! On Thu, Jan 31, 2013 at 11:35 AM, Jason Keene <jasonkeene@gmail.com> wrote:
Why do function definitions require parens?
class MyClass: ... pass ... def my_func: File "<stdin>", line 1 def my_func: ^ SyntaxError: invalid syntax
This seems to me to break a symmetry with class definitions. I assume this is just a hold off from C, perhaps there is a non-historical reason tho.
I believe in the past we've forced parens in list comprehensions to create a symmetry between comprehensions/generator expressions. Why not for this?
Jason Keene wrote:
Just to be clear, I wasn't suggesting forcing parens for class definitions. Rather make them optional for functions!
That would introduce an asymmetry between function definitions and function calls -- parens would be required in the call but not the definition. And before you say that this asymmetry currently exists between class definitions and class instantiations, it's not the same situation. What goes between the parens in a class definition is the base classes, not the arguments to the constructor. -- Greg
On 2013-01-31 16:35, Jason Keene wrote:
Why do function definitions require parens?
class MyClass: ... pass ... def my_func: File "<stdin>", line 1 def my_func: ^ SyntaxError: invalid syntax
This seems to me to break a symmetry with class definitions. I assume this is just a hold off from C, perhaps there is a non-historical reason tho.
I believe in the past we've forced parens in list comprehensions to create a symmetry between comprehensions/generator expressions. Why not for this?
The parentheses are always required when calling the function, so it makes sense to always require them when defining the function. The case with class definitions is different; they are used in the definition only when you want to specify the superclass. They are always required when creating an instance of the class and in method definitions.
On 01/31/2013 09:15 AM, MRAB wrote:
On 2013-01-31 16:35, Jason Keene wrote:
Why do function definitions require parens?
class MyClass: ... pass ... def my_func: File "<stdin>", line 1 def my_func: ^ SyntaxError: invalid syntax
This seems to me to break a symmetry with class definitions. I assume this is just a hold off from C, perhaps there is a non-historical reason tho.
The parentheses are always required when calling the function, so it makes sense to always require them when defining the function.
The case with class definitions is different; they are used in the definition only when you want to specify the superclass.
... they are required in the definition when you want to specify the superclass, and optional otherwise. ~Ethan~
On 1/31/2013 12:15 PM, MRAB wrote:
On 2013-01-31 16:35, Jason Keene wrote:
Why do function definitions require parens?
class MyClass: ... pass ... def my_func: File "<stdin>", line 1 def my_func: ^ SyntaxError: invalid syntax
This seems to me to break a symmetry with class definitions. I assume this is just a hold off from C, perhaps there is a non-historical reason tho.
I believe in the past we've forced parens in list comprehensions to create a symmetry between comprehensions/generator expressions. Why not for this?
The parentheses are always required when calling the function, so it makes sense to always require them when defining the function.
The case with class definitions is different; they are used in the definition only when you want to specify the superclass.
I think parens for super class are an unfortunate syntax, since it looks just like arguments to the class and is confusing for some beginners: def function(arg): ... function(10) # Similar syntax: 10 corresponds to arg class Thing(Something): ... thing = Thing(10) # How does 10 relate to Something? It doesn't. A better syntax (which I AM NOT PROPOSING) would be: class Thing from Something: --Ned.
They are always required when creating an instance of the class and in method definitions. _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On Fri, Feb 1, 2013 at 5:11 AM, Ned Batchelder <ned@nedbatchelder.com> wrote:
I think parens for super class are an unfortunate syntax, since it looks just like arguments to the class and is confusing for some beginners:
def function(arg): ... function(10) # Similar syntax: 10 corresponds to arg
class Thing(Something): ... thing = Thing(10) # How does 10 relate to Something? It doesn't.
A better syntax (which I AM NOT PROPOSING) would be:
class Thing from Something:
What about class Thing = Something: pass I am not proposing this either, but it would emphasize the difference between superclasses and __init__ args. But really, parens are used in many different ways. There doesn't need to be a logical parallel between generator expressions and function calls, for instance. ChrisA
Other strange thing is that the `raise` statement doesn't require to instantiate an Exception object, allowing to pass an Exception class to it. raise NotImplementedError raise NotImplementedError() Is there any difference between this two lines of code? And there is nothing about that fact in python docs. (or I just not found?..) -- Andrew 31.01.2013 20:35, Jason Keene ?????:
Why do function definitions require parens?
class MyClass: ... pass ... def my_func: File "<stdin>", line 1 def my_func: ^ SyntaxError: invalid syntax
This seems to me to break a symmetry with class definitions. I assume this is just a hold off from C, perhaps there is a non-historical reason tho.
I believe in the past we've forced parens in list comprehensions to create a symmetry between comprehensions/generator expressions. Why not for this?
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On Jan 31, 2013, at 11:33 PM, Andrew Grigorev wrote:
Other strange thing is that the `raise` statement doesn't require to instantiate an Exception object, allowing to pass an Exception class to it.
raise NotImplementedError raise NotImplementedError()
Is there any difference between this two lines of code?
The main difference (I *think* this is still true) is that in the first example, if the exception is caught in C it can avoid instantiation. Cheers, -Barry
On 1/31/2013 4:06 PM, Barry Warsaw wrote:
On Jan 31, 2013, at 11:33 PM, Andrew Grigorev wrote:
Other strange thing is that the `raise` statement doesn't require to instantiate an Exception object, allowing to pass an Exception class to it.
raise NotImplementedError raise NotImplementedError()
Is there any difference between this two lines of code?
Questions like this below on python-list, not here.
The main difference (I *think* this is still true) is that in the first example, if the exception is caught in C it can avoid instantiation.
The the second form allows addition of a message, which is usually a good idea. -- Terry Jan Reedy
On 01/02/13 03:35, Jason Keene wrote:
Why do function definitions require parens?
class MyClass: ... pass ... def my_func: File "<stdin>", line 1 def my_func: ^ SyntaxError: invalid syntax
This seems to me to break a symmetry with class definitions.
Why do you think that class definitions and function definitions should be symmetrical? -- Steven
In a way they do the same thing, they both create an object (function/class) from a suite and assign it to the name given after the keyword (def/class). Sure they do totally different things with the suite in creating the object, but in essence it's a name assignment. On Thursday, January 31, 2013, Steven D'Aprano wrote:
On 01/02/13 03:35, Jason Keene wrote:
Why do function definitions require parens?
class MyClass:
... pass ...
def my_func:
File "<stdin>", line 1 def my_func: ^ SyntaxError: invalid syntax
This seems to me to break a symmetry with class definitions.
Why do you think that class definitions and function definitions should be symmetrical?
-- Steven ______________________________**_________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/**mailman/listinfo/python-ideas<http://mail.python.org/mailman/listinfo/python-ideas>
Jason Keene <jasonkeene@gmail.com> writes:
In a way they do the same thing, they both create an object (function/class) from a suite and assign it to the name given after the keyword (def/class). Sure they do totally different things with the suite in creating the object, but in essence it's a name assignment.
In a way, ‘import’ and ‘break’ do the same thing, they trigger the compiler to compile a particular set of code bytes. Sure the code bytes do totally different things, but in essence it's a statement. Less facetiously: You can blur your vision as much as you like to make ‘class’ and ‘def’ look similar, but that doesn't diminish the importance of the distinctions you're ignoring. -- \ “Always do right. This will gratify some people, and astonish | `\ the rest.” —Mark Twain | _o__) | Ben Finney
Both class and function definitions produce callable objects that are assigned to a name with nearly identical syntax. I don't think your analogy with import/break statements is valid. Additionally, both definitions produce very similar byte codes: 3 MAKE_FUNCTION 0 6 STORE_FAST 0 (my_func) 9 MAKE_FUNCTION 0 12 CALL_FUNCTION 0 15 BUILD_CLASS 16 STORE_FAST 0 (MyClass) The only argument I see for requiring empty parens in function definitions is a historical one. On Thursday, January 31, 2013, Ben Finney wrote:
Jason Keene <jasonkeene@gmail.com <javascript:;>> writes:
In a way they do the same thing, they both create an object (function/class) from a suite and assign it to the name given after the keyword (def/class). Sure they do totally different things with the suite in creating the object, but in essence it's a name assignment.
In a way, ‘import’ and ‘break’ do the same thing, they trigger the compiler to compile a particular set of code bytes. Sure the code bytes do totally different things, but in essence it's a statement.
Less facetiously: You can blur your vision as much as you like to make ‘class’ and ‘def’ look similar, but that doesn't diminish the importance of the distinctions you're ignoring.
-- \ “Always do right. This will gratify some people, and astonish | `\ the rest.” —Mark Twain | _o__) | Ben Finney
_______________________________________________ Python-ideas mailing list Python-ideas@python.org <javascript:;> http://mail.python.org/mailman/listinfo/python-ideas
class MyClass(): pass class MyClass: pass def my_func(): pass def my_func: pass File "<stdin>", line 1 def my_func: ^ SyntaxError: invalid syntax
http://www.youtube.com/watch?v=etuPF1yJRzg If only more of us grew up watching sesame street. On Friday, February 1, 2013, Jason Keene wrote:
Both class and function definitions produce callable objects that are assigned to a name with nearly identical syntax. I don't think your analogy with import/break statements is valid. Additionally, both definitions produce very similar byte codes:
3 MAKE_FUNCTION 0 6 STORE_FAST 0 (my_func)
9 MAKE_FUNCTION 0 12 CALL_FUNCTION 0 15 BUILD_CLASS 16 STORE_FAST 0 (MyClass)
The only argument I see for requiring empty parens in function definitions is a historical one.
On Thursday, January 31, 2013, Ben Finney wrote:
Jason Keene <jasonkeene@gmail.com> writes:
In a way they do the same thing, they both create an object (function/class) from a suite and assign it to the name given after the keyword (def/class). Sure they do totally different things with the suite in creating the object, but in essence it's a name assignment.
In a way, ‘import’ and ‘break’ do the same thing, they trigger the compiler to compile a particular set of code bytes. Sure the code bytes do totally different things, but in essence it's a statement.
Less facetiously: You can blur your vision as much as you like to make ‘class’ and ‘def’ look similar, but that doesn't diminish the importance of the distinctions you're ignoring.
-- \ “Always do right. This will gratify some people, and astonish | `\ the rest.” —Mark Twain | _o__) | Ben Finney
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On 2/1/2013 12:21 AM, Jason Keene wrote:
Both class and function definitions produce callable objects that are assigned to a name with nearly identical syntax. I don't think your analogy with import/break statements is valid. Additionally, both definitions produce very similar byte codes:
3 MAKE_FUNCTION 0 6 STORE_FAST 0 (my_func)
9 MAKE_FUNCTION 0 12 CALL_FUNCTION 0 15 BUILD_CLASS 16 STORE_FAST 0 (MyClass)
The only argument I see for requiring empty parens in function definitions is a historical one.
That's because you're ignoring the main one: function calls require parens, so function definitions also require them. --Ned.
On Thursday, January 31, 2013, Ben Finney wrote:
Jason Keene <jasonkeene@gmail.com <javascript:;>> writes:
> In a way they do the same thing, they both create an object > (function/class) from a suite and assign it to the name given after the > keyword (def/class). Sure they do totally different things with the suite > in creating the object, but in essence it's a name assignment.
In a way, 'import' and 'break' do the same thing, they trigger the compiler to compile a particular set of code bytes. Sure the code bytes do totally different things, but in essence it's a statement.
Less facetiously: You can blur your vision as much as you like to make 'class' and 'def' look similar, but that doesn't diminish the importance of the distinctions you're ignoring.
-- \ "Always do right. This will gratify some people, and astonish | `\ the rest." ---Mark Twain | _o__) | Ben Finney
_______________________________________________ Python-ideas mailing list Python-ideas@python.org <javascript:;> http://mail.python.org/mailman/listinfo/python-ideas
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On Thu, Jan 31, 2013 at 10:21 PM, Jason Keene <jasonkeene@gmail.com> wrote:
Additionally, both definitions produce very similar byte codes:
3 MAKE_FUNCTION 0 6 STORE_FAST 0 (my_func)
9 MAKE_FUNCTION 0 12 CALL_FUNCTION 0 15 BUILD_CLASS 16 STORE_FAST 0 (MyClass)
That's just an implementation detail. -eric
participants (12)
-
Andrew Grigorev -
Barry Warsaw -
Ben Finney -
Chris Angelico -
Eric Snow -
Ethan Furman -
Greg Ewing -
Jason Keene -
MRAB -
Ned Batchelder -
Steven D'Aprano -
Terry Reedy