[Python-ideas] pep-0484 - Forward references and Didactics - be orthogonal

[Steven D'Aprano]

On Tue, Aug 25, 2015 at 02:24:45PM -0700, Andrew Barnert wrote:
> On Aug 25, 2015, at 09:56, Steven D'Aprano <steve at pearwood.info> wrote:
> > 
> >> On Tue, Aug 25, 2015 at 01:35:24AM -0700, Andrew Barnert wrote:
> >>> On Aug 24, 2015, at 19:52, Steven D'Aprano <steve at pearwood.info> wrote:
> >>> 
> >>> I agree that is desirable, but surely many languages have some sort of 
> >>> forward declaration syntax? I know that both the Pascal and C families 
> >>> of languages do.
> >> 
> >> What would a forward declaration mean in Python?
> > 
> > I thought it was obvious from context, not to mention from the example 
> > given by the OP.
> 
> I thought it was obvious, until you brought up C and Pascal, whose 
> forward references are a pretty different thing from what PEP 484 and 
> the OP's example imply, and whose compilation process is radically 
> different from Python's. If you meant the same thing as the PEP, then 
> the shorter answer is: I don't think there's anything useful to learn 
> from C here. 

In context, I was explicitly replying to the OPs comment about "needing" 
to annotate methods with the class object itself, rather than using a 
string, because "_one_ concept should work in different circumstances". 
I was pointing out that other languages make do with two concepts, and 
have their own ways of dealing with the problem of referring to 
something which doesn't exist yet. I wasn't suggesting that we copy what 
C, or any other language, does.

To be honest, I thought that my post was pretty clear that far from 
thinking there is a problem to be solved, the use of string literals 
like 'Tree' is not just an acceptable solution to the problem, but it is 
an elegant solution to the problem. As I see it:

- adding some sort of complicated, ad hoc special case to allow forward 
  references would be a nasty hack and should be rejected;

- large changes to the language (e.g. swapping to a two-pass compile 
  process, to allow function and class hoisting) would eliminate the 
  problem but break backwards compatibility and is a huge change for 
  such a minor issue.

I don't see this as needing anything more than teaching the students how 
Python's execution model actually works, plus a simple work-around for 
annotations within a class (use the class name as a string).


-- 
Steve