The perfect Python

[Terry Reedy]

"Jean-François Ménard" <jeanfrancoismenard at msn.com> wrote in message
news:jz5b9.64868$2J5.463152 at weber.videotron.net...
> What is missing ?  Well, I'm not a language designer, but I can say
what *I* miss.

>     - Class variables.

Already have this.  Name bound to a class object *are* class
variables.  They are initialized in the class statement.  Names bound
to an instance object *are* instance variables.  They are initialized
in the __init__() method.  Perhaps you should study and understand
Python better before claiming that basic things present are missing.
Or better explain what you *think* is missing.

>     - Design by contract. Pre and Post conditions.  Could save hours
of debugging.

Already have general and turnoffable condition checker -- assert --
with optional error message:

>     public functionWithAssertion(Param1):
>         """ Design by Contract """
>         require:
>             """ Precondition """
>             Param1 < 1000000

   assert Param1 < 1000000, 'functionWithAssertion precondition'

>         do:
>             """ Function body """
>             pass
>         ensure:
>             """ Poscondition """
>             Param1 < 1000000

   assert Param1 < 1000000, 'functionWithAssertion postcondition'

>     - No more self in functions declarations.  In OOP, this *can* be
> implicit. (I know, this is controversial stuff)

So why bring it up again?  There was a recent long and tedious thread
in which some of us explained multiple times why this is inconsistent
with the current design of Python.  Please reread (use google if
needed).  In any case, the issue of the first parameter is only
relevant to the subset of functions wrapped as methods.

>    - Private and Public scopes.  Explicitly.  No more
__name_mangling

Surface question: why is typing 'public' or 'private' for every
initial class attribute better than occasionally typing '__'?  (I
personally find the idea horrid.)  Deeper question: what about later
attribute assignments?  Prohibit them or make such attributes
implicitly publicc?

Not only is Python not C++, it is not even prettified C++.  It is
based on an entirely different model of the relationship between data,
types, names, and variables.

>     - Standard GUI library.  AnyGui seems to be the solution, but
> development seems to have stalled recently...

People who use and like TK/inter consider *that* to be the standard
(lowercase 's') Python GUI.  Both Python org and ActiveState package
it in their Windows binary distributions.  Do you really want Guido
etal to aggressive push it as the *Standard* (capital 'S') by
requiring that it be a part of all Python distributions and by
discouraging the discussion of use of anything else?

Terry J. Reedy