FAQ

On 8/25/2015 12:19 PM, Erik Bray wrote:
On Tue, Aug 25, 2015 at 11:15 AM, Terry Reedy wrote:
2. Class statements would initially create an empty class bound to the class
name. This could break back compatibility, and would require cleanup in
case of a syntax error in the body. This would be similar to import
statements initially putting a empty module in sys.modules to support
circular imports. This is messy and still bug prone is use.

'in use'.

I have been thinking about this lately in a different context, and I
would very much favor this approach. I think in large part because it
works this way for modules it would make sense for it to work for
classes as well. The fact that ClassName is bound to an object that
will *eventually* become the class as soon as the parser has read in:

class ClassName:

represents, to me (and I would suspect to many students as well), the
least astonishment.

I realize it would be a very non-trivial change, however.

It might be more useful to have def statements work that way (bind name
to blank function object). Then


def fac(n, _fac=fac): # less confusing than 'fac=fac'
      return _fac(n-1)*n if n > 1 else 1


would actually be recursive regardless of external name bindings.


But as is the case with modules, exposing incomplete objects easily
leads to buggy code, such as def f(n, code=f.__code__): pass

what students have to write instead:

#-------------bad workaround----------------------------\
class Tree:
def __init__(self, left: 'Tree', right: 'Tree'):
self.left = left
self.right = right
What about:
class Tree:
... """Forward declaration of Tree type."""
...
class Tree(Tree):
... """Tree implementation."""
... def __init__(self, left: Tree, right: Tree):
... self.left = left
... self.right = right

A little ugly, and potentially error-prone (but only, I think, in
exceptional cases). It's also a decent opportunity to teach something
about forward-declaration, which I think is worth knowing about. And
I think this makes what's going on clearer than the string-based
workaround.

I like this better than my decorator version. Notice that if Python were
changed so that 'Tree' were bound to a blank class first thing, then
Tree(Tree) would be subclassing itself, breaking code like the above
unless a special rule was added to remove a class from its list of
subclasses.


--
Terry Jan Reedy

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 14 of 28 | next ›
Discussion Overview
grouppython-ideas @
categoriespython
postedAug 24, '15 at 4:19a
activeAug 28, '15 at 7:21p
posts28
users10
websitepython.org

People

Translate

site design / logo © 2017 Grokbase