> I'll demonstrate here in a short interactive session (which you can
> reproduce using IDLE with the -n switch as usual), why the solution
> Martin proposes doesn't meet the requirements I tried to accomplish with
> my code. This session 'simulates' a student curiously playing around and
> experimenting with *the* Screen():
> 
>>>> from turtle import Screen, Turtle
>>>> class YellowScreen(Screen):
> 	def __init__(self):
> 		Screen.__init__(self)
> 		self.bgcolor("yellow")

Hmm. Why is it important to be able to inherit from Screen? I don't
think inheritance from a singleton is a meaningful concept, and I
believe that students are misguided when they are told that this is
the way to produce yellow screen. Instead, they should write

def YellowScreen():
    s = Screen()
    s.bgcolor("yellow")
    return s

This much better captures the notion of a singleton object: you can
not *create* them, but you have to *modify* them.

>>>> s1 = Screen()
>>>> s1.bgcolor("pink")

This is really confusing. It does *not* create a new screen, but
modifies the existing one. How can you tell your students the meaning
of object creation in the light of this strange behavior?

So I urge you to reconsider that inheritance from Screen should
be deliberately dropped. It is a flawed, undesirable concept.

> Nevertheless I decisively
> propose to accept this behaviour in order to be able do things like the
> ones demonstrated above.

You can do the things you want to just as fine with functions.

> Morover I also consider it to be a benefit to
> use spezialized and/or reusable screens derived from the Screen() class
> in scripts, what would not be possible with a Screen()-function
> returning *the* single _Screen() object. (All this meant in the context
> of teaching and learning OOP).

Not at all. It would be very easy with a Screen function.

> But if you think, that there is no way around and it has to be
> observed strictly, one had to leave everything as is and find a
> better solution (with the desired behaviour) for 2.6.1.

I propose that Screen is change to a function for 2.6. This is the
more restrictive solution (not allowing inheritance). If inheritance
would be allowed now, it could be taken back for backwards
compatibility. However, if it is changed to a function now, it can
be changed back to a class later.

> Anyway I'd like to express my hope that this controversial
> implementation of the last element in the class hierarchy for a very
> special purpose is *not* a hint at a design bug of the entire class
> hierarchy.

Perhaps not of the entire hierarchy, but certainly of the Screen class
and its potential subclasses.