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

[Paul Boddie]

On 5 Sep, 21:02, Kenneth McDonald <kenneth.m.mcdon... at sbcglobal.net>
wrote:
> 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.

I think there's been a widespread "kitchen sink" mentality around the
Python language for some time, which is where the multimethods
proposal, amongst others, fits in here. If we look at a selection of
PEPs, this trend is quite evident even amongst those accepted for
inclusion:

  PEP 3102 (Keyword-Only Arguments) - provides some benefits, but with
           an odd syntax and still more gymnastics for each function
           call.

  PEP 3104 (Access to Names in Outer Scopes) - syntactically a very
           large bikeshed indeed, but will keep the closure-happy
           people happy.

  PEP 3105 (Make print a function) - laudable, but leads to the not
           particularly flattering observation that someone made about
           Python 3.0 breaking "hello world". "Real men" don't use
           print, apparently, but a print function will presumably let
           them show their gentler side (or embrace the dark side).

  PEP 3107 (Function Annotations) - otherwise known as the freedom for
           developers to annotate the hell out of functions for the
           purpose of stating type information explicitly, although
           they're not really for that, apparently. <nudge> <wink>
           Expect n lines of decorators plus n lines of function
           signature in shinier code bases.

Eventually, we get to PEP 3113 (Removal of Tuple Parameter Unpacking)
which is a clean-up. Meanwhile, PEP 3108 (Standard Library
Reorganization) gets a mere wave of the hand with respect to core
development priorities. Oh sure, we've got Python Eggs and can
potentially unbundle everything these days - although I note that the
CPython runtime itself doesn't get more modular and is seemingly
resistant to attempts to make it easier to cross-compile - so perhaps
one of Python's biggest selling points (the batteries included, now
corroding in the battery compartment) isn't that important. I'll
accept that the new I/O system (PEP 3116) could be beneficial, and I
don't underestimate the effort put in by Martin von Löwis and others
to tidy up and clarify certain awkward matters (PEPs 3120, 3121,
3131), but as people increasingly demand more innovation from the
runtime, what we get is stuff like the renaming of various methods and
PEP 3101 (Advanced String Formatting).

> 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#.

Despite my own feeling that properties are overrated, possibly due to
experience with languages and systems whose developers don't fear
showing method invocations off, I guess this is just one area where
some backward incompatibility breakage could have produced a "high
value" syntax enhancement.

> 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...?

I've tried to track the things people previously complained about and
any remedies for those things in Python 3000. See here for details:

http://wiki.python.org/moin/PythonWarts

> 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.

I'm not really a fan of docstring markup languages and tend to switch
as much of that off as possible in tools like epydoc. This comes from
having to work on code bases with documentation comments like the
following:

/**
 * TODO - What does this function do?
 * @param horse Horse The Horse
 * @param dereferencer SpecialDereferencer The SpecialDereferencer
 * @param options AnimalOptions AnimalOptions
 */
void Paddock::InitP97(Horse& horse, SpecialDereferencer* dereferencer,
AnimalOptions options)

I've not completely abandoned the hope that one day we'll get half
decent type information in generated documentation without having to
write it over and over again in docstrings, even for Python code.

Paul