Any syntactic cleanup likely for Py3? And what about doc standards?

[Ferenczi Viktor]

Hi!

> The reading I've done so far on Python 3 (alpha announcement, meta-PEP,
> some other PEPs) is generally encouraging, but there doesn't seem to be
> much on cleaning up the syntax, which has become uglier over time as
> features have been added on to an original syntax that wasn't designed
> to support them. It seems to me (from what little I've read--I admit
> that it's impossible to know for sure without experimenting quite a bit,
> for which I don't currently have the time) that new features such as
> multimethods might just make things more confusing (especially for
> newbies) in a lot of ways, without appropriate syntactic support.

There are some cleanups, such as the new class decorators and function 
annotation syntax. Both of them provides a common, much better solution 
instead of current weird solutions, such as metaclasses and specially 
formatted docstrings. Since Python currenty has a very nice syntax it cannot 
be cleaned up much further.

> Currently the most obvious example of this is Python 2.5's way of
> defining properties, which is ugly. leads often to writing of
> unnecessary code, and certainly doesn't make property code clear to a
> reader. Contrast this to the way properties (things that look like an
> instance variable but are actually bound to methods) are handled in Ruby
> and (IIRC, this also does a decent job) C#.
> On the other hand, it does seem that some new syntactic support for
> other features will be added, so perhaps I'm just missing whichever PEPs
> talk about going back and adding cleaner syntax for existing features...?

Class decorators allows clean implementation of properties.
Detailed description: http://www.python.org/dev/peps/pep-3129/
Lets use a hypothetic library providing properties, for example:

from property_support import hasProperties, Property

@hasProperties
class Sphere(object):
    def setRadius(self, value):
        ... some setter implementation ...
    radius=Property(default=1.0, set=setRadius, type=(int, float))
    color=Property(default='black', allowNone=True)

This is a cleaner syntax if you need automatic default setter/getter 
implementations with type checking, default values, etc. You can optionally 
override/extend some of the default implementations. This could be 
implemented by a third party library using class decorators and need not be 
restricted by a strict syntax in the language itself. This is a good design 
choice from my point of view, since it does not require the introduction of 
new symbols into the syntax, fully dynamic and inspected at runtime.

> Finally, another thing I've perhaps missed, but I can't see anything in
> what I've gone through, about correcting of of what I see to be one of
> Python's most long-standing really serious flaws, which is the lack of
> an official standard documentation markup syntax for writing
> documentation in code. This isn't even a matter of getting something
> developed, it's simply a matter of Guido and the Powers That Be
> bestowing their benediction on one of the several adequate or better
> documentation toolsets out there, so that more of us (slowly) start
> using it. Eventually this will result in work on the toolset itself,
> more people will be willing to use it, and there'll be a nice virtuous
> circle. Given how much more capable D'Oxygen is than any of the
> Python-specific solutions, I'd vote for D'Oxygen myself, but I'd prefer
> to have almost anything fill in this vacuum, rather than continue things
> the way they are.

Maybe the community should ask Guido to suggest a
"preferred" tool for documenting Python code.

Regars, Viktor