Requesting that a class be a new-style class
This is something I've typed way too many times: Py> class C(): File "<stdin>", line 1 class C(): ^ SyntaxError: invalid syntax It's the asymmetry with functions that gets to me - defining a function with no arguments still requires parentheses in the definition statement, but defining a class with no bases requires the parentheses to be omitted. Which leads in to the real question: Does this *really* need to be a syntax error? Or could it be used as an easier way to spell "class C(object):"? Then, in Python 3K, simply drop support for omitting the parentheses from class definitions - require inheriting from ClassicClass instead. This would also have the benefit that the elimination of defaulting to classic classes would cause a syntax error rather than subtle changes in behaviour. Cheers, Nick. -- Nick Coghlan | ncoghlan@email.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.skystorm.net
On 2005 Feb 19, at 06:03, Nick Coghlan wrote:
This is something I've typed way too many times:
Py> class C(): File "<stdin>", line 1 class C(): ^ SyntaxError: invalid syntax
It's the asymmetry with functions that gets to me - defining a function with no arguments still requires parentheses in the definition statement, but defining a class with no bases requires the parentheses to be omitted.
Seconded. It's always irked me enough that it's the only ``apology'' for Python syntax you'll see in the Nutshell -- top of p. 71, "The syntax of the class statement has a small, tricky difference from that of the def statement" etc.
Which leads in to the real question: Does this *really* need to be a syntax error? Or could it be used as an easier way to spell "class C(object):"?
-0 ... instinctively, I dread the task of explaining / teaching about the rationale for this somewhat kludgy transitional solution [[empty parentheses may be written OR omitted, with large difference in meaning, not very related to other cases of such parentheses]], even though I think you're right that it would make the future transition to 3.0 somewhat safer. Alex
This is something I've typed way too many times:
Py> class C(): File "<stdin>", line 1 class C(): ^ SyntaxError: invalid syntax
It's the asymmetry with functions that gets to me - defining a function with no arguments still requires parentheses in the definition statement, but defining a class with no bases requires the parentheses to be omitted.
Seconded. It's always irked me enough that it's the only ``apology'' for Python syntax you'll see in the Nutshell -- top of p. 71, "The syntax of the class statement has a small, tricky difference from that of the def statement" etc.
+1 For me, this would come-up when experimenting with mixins. Adding and removing a mixin usually entailed a corresponding change to the parentheses. Raymond
But... only as an additional option, not as a replacement, right? Michael On Sat, 19 Feb 2005 03:01:14 -0500, Raymond Hettinger <python@rcn.com> wrote:
This is something I've typed way too many times:
Py> class C(): File "<stdin>", line 1 class C(): ^ SyntaxError: invalid syntax
It's the asymmetry with functions that gets to me - defining a function with no arguments still requires parentheses in the definition statement, but defining a class with no bases requires the parentheses to be omitted.
Seconded. It's always irked me enough that it's the only ``apology'' for Python syntax you'll see in the Nutshell -- top of p. 71, "The syntax of the class statement has a small, tricky difference from that of the def statement" etc.
+1 For me, this would come-up when experimenting with mixins. Adding and removing a mixin usually entailed a corresponding change to the parentheses.
Raymond
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com
Nick Coghlan <ncoghlan@iinet.net.au> writes:
This is something I've typed way too many times:
Py> class C(): File "<stdin>", line 1 class C(): ^ SyntaxError: invalid syntax
It's the asymmetry with functions that gets to me - defining a function with no arguments still requires parentheses in the definition statement, but defining a class with no bases requires the parentheses to be omitted.
Yeah, this has annoyed me for ages too. However! You obviously haven't read Misc/HISTORY recently enough :) The surprising thing is that "class C():" used to work (in fact before 0.9.4 the parens mandatory). It became a syntax error in 0.9.9, seemingly because Guido was peeved that people hadn't updated all their old code to the new syntax. I wonder if he'd like to try that trick again today :) I'd still vote for it to be changed.
Which leads in to the real question: Does this *really* need to be a syntax error? Or could it be used as an easier way to spell "class C(object):"?
-1. Too magical, too opaque.
Then, in Python 3K, simply drop support for omitting the parentheses from class definitions - require inheriting from ClassicClass instead.
HISTORY repeats itself... Cheers, mwh -- [Perl] combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. -- Jamie Zawinski
This is something I've typed way too many times:
Py> class C(): File "<stdin>", line 1 class C(): ^ SyntaxError: invalid syntax
It's the asymmetry with functions that gets to me - defining a function with no arguments still requires parentheses in the definition statement, but defining a class with no bases requires the parentheses to be omitted.
It's fine to fix this in 2.5. I guess I can add this to my list of early oopsies -- although to the very bottom. :-) It's *not* fine to make C() mean C(object). (We already have enough other ways to declaring new-style classes.) -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
This is something I've typed way too many times:
Py> class C(): File "<stdin>", line 1 class C(): ^ SyntaxError: invalid syntax
It's the asymmetry with functions that gets to me - defining a function with no arguments still requires parentheses in the definition statement, but defining a class with no bases requires the parentheses to be omitted.
It's fine to fix this in 2.5. I guess I can add this to my list of early oopsies -- although to the very bottom. :-)
It's *not* fine to make C() mean C(object). (We already have enough other ways to declaring new-style classes.)
Fair enough - the magnitude of the semantic difference between "class C:" and "class C():" bothered me a little, too. I'll just have to remember that I can put "__metaclass__ == type" at the top of modules :) Cheers, Nick. -- Nick Coghlan | ncoghlan@email.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.skystorm.net
On Sun, Feb 20, 2005 at 12:13:25PM +1000, Nick Coghlan wrote:
Guido van Rossum wrote:
This is something I've typed way too many times:
Py> class C(): File "<stdin>", line 1 class C(): ^ SyntaxError: invalid syntax
It's the asymmetry with functions that gets to me - defining a function with no arguments still requires parentheses in the definition statement, but defining a class with no bases requires the parentheses to be omitted.
It's fine to fix this in 2.5. I guess I can add this to my list of early oopsies -- although to the very bottom. :-)
It's *not* fine to make C() mean C(object). (We already have enough other ways to declaring new-style classes.)
Fair enough - the magnitude of the semantic difference between "class C:" and "class C():" bothered me a little, too. I'll just have to remember that I can put "__metaclass__ == type" at the top of modules :)
I always use new style classes so I only have to remember one set of behaviors. "__metaclass__ = type" is warty, it has the "action at a distance" problem that decorators solve for functions. I didn't dig into the C but does having 'type' as metaclass guarantee the same behavior as inheriting 'object' or does object provide something type doesn't? *wince* Py3k? Faster please[*]. -Jack * a US-ism of a conservative bent, loosely translated as "change for the better? I'll get behind that."
I didn't dig into the C but does having 'type' as metaclass guarantee the same behavior as inheriting 'object' or does object provide something type doesn't? *wince*
No, they're equivalent. __metaclass__ = type cause the base class to be object, and a base class of object causes the metaclass to be type. But I agree wholeheartedly: class C(object): is much preferred. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On 2005 Feb 20, at 04:35, Jack Diederich wrote:
I always use new style classes so I only have to remember one set of behaviors.
I agree: that's reason #1 I recommend always using new-style whenever I teach / tutor / mentor in Python nowadays.
"__metaclass__ = type" is warty, it has the "action at a distance" problem that decorators solve for functions.
I disagree. I view it as akin to a "from __future__ import" except that -- since the compiler doesn't need-to-know, as typeclass-picking happens at runtime -- it was accomplished by less magical and more flexible means.
I didn't dig into the C but does having 'type' as metaclass guarantee the same behavior as inheriting 'object' or does object provide something type doesn't? *wince*
I believe the former holds, since for example:
class X: __metaclass__ = type ... X.__bases__ (<type 'object'>,)
If you're making a newstyle class with an oldstyle base, it's different:
class Y: pass ... class X(Y): __metaclass__ = type ... Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: Error when calling the metaclass bases a new-style class can't have only classic bases
in this case, you do need to inherit object explicitly:
class X(Y, object): pass ... X.__bases__ (<class __main__.Y at 0x38d330>, <type 'object'>) type(X) <type 'type'>
This is because types.ClassType turns somersaults to enable this: in this latter construct, Python's mechanisms determine ClassType as the metaclass (it's the metaclass of the first base class), but then ClassType in turn sniffs around for another metaclass to delegate to, among the supplied bases, and having found one washes its hands of the whole business;-). Alex
Alex Martelli <aleax@aleax.it> writes:
On 2005 Feb 20, at 04:35, Jack Diederich wrote:
I didn't dig into the C but does having 'type' as metaclass guarantee the same behavior as inheriting 'object' or does object provide something type doesn't? *wince*
I believe the former holds, since for example:
I was going to say that 'type(object) is type' is everything you need to know, but you also need the bit of code in type_new that replaces an empty bases tuple with (object,) -- but class C: __metaclass__ = Type and class C(object): pass produce identical classes.
This is because types.ClassType turns somersaults to enable this: in this latter construct, Python's mechanisms determine ClassType as the metaclass (it's the metaclass of the first base class), but then ClassType in turn sniffs around for another metaclass to delegate to, among the supplied bases, and having found one washes its hands of the whole business;-).
It's also notable that type_new does exactly the same thing! Cheers, mwh -- <etrepum> Jokes around here tend to get followed by implementations. -- from Twisted.Quotes
At 09:15 AM 2/20/05 +0100, Alex Martelli wrote:
This is because types.ClassType turns somersaults to enable this: in this latter construct, Python's mechanisms determine ClassType as the metaclass (it's the metaclass of the first base class), but then ClassType in turn sniffs around for another metaclass to delegate to, among the supplied bases, and having found one washes its hands of the whole business;-).
To be pedantic, the actual algorithm in 2.2+ has nothing to do with the first base class; that's the pre-2.2 algorithm. The 2.2 algorithm looks for the most-derived metaclass of the base classes, and simply ignores classic bases altogether.
This is something I've typed way too many times:
Py> class C(): File "<stdin>", line 1 class C(): ^ SyntaxError: invalid syntax
It's the asymmetry with functions that gets to me - defining a function with no arguments still requires parentheses in the definition statement, but defining a class with no bases requires the parentheses to be omitted.
It's fine to fix this in 2.5.
Yea! Raymond
Guido van Rossum wrote:
This is something I've typed way too many times:
Py> class C(): File "<stdin>", line 1 class C(): ^ SyntaxError: invalid syntax
It's the asymmetry with functions that gets to me - defining a function with no arguments still requires parentheses in the definition statement, but defining a class with no bases requires the parentheses to be omitted.
It's fine to fix this in 2.5. I guess I can add this to my list of early oopsies -- although to the very bottom. :-)
It's *not* fine to make C() mean C(object). (We already have enough other ways to declaring new-style classes.)
OK, this is now in thanks to the following revisions: Checking in Grammar/Grammar; /cvsroot/python/python/dist/src/Grammar/Grammar,v <-- Grammar new revision: 1.53; previous revision: 1.52 done Checking in Python/graminit.c; /cvsroot/python/python/dist/src/Python/graminit.c,v <-- graminit.c new revision: 2.39; previous revision: 2.38 done Checking in Python/compile.c; /cvsroot/python/python/dist/src/Python/compile.c,v <-- compile.c new revision: 2.349; previous revision: 2.348 done Checking in Misc/NEWS; /cvsroot/python/python/dist/src/Misc/NEWS,v <-- NEWS new revision: 1.1267; previous revision: 1.1266 done -Brett
participants (9)
-
Alex Martelli -
Brett C. -
Guido van Rossum -
Jack Diederich -
Michael Hudson -
Michael Walter -
Nick Coghlan -
Phillip J. Eby -
Raymond Hettinger