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

[Kenneth McDonald]

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.

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

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.

As I say, I don't get the time I'd like to put into reading up on Py3,
so please feel free to correct, point out references, etc. etc.

Thanks,
Ken

 

[Paul Boddie]

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

 

[Kay Schluehr]

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.

Maybe that's one of two fixed points in the evolution of a programming
language? The other one might be an almost non-designed and small
language with a vast and flat library a la PHP and Zend. Apparently
even Scheme moves into the kitchen sink today with the new R6RS
specification.

Python is going to be the-right-thing with abandoning the print
statement or making lists a bit more monotyped with a type aware sort.
The worse-is-better philosophy on the other hand is indifferent
towards stylistic consistency and equipped with less nominalistic
pedantry ( "this is a list and therefore you only have to use it as a
list and not as a multiset..." ).

This explains also the lack of interest into the std library which
will be reduced to CPython services and basic datatypes. But there are
also organizational issues and I don't even think that a lib that
provides applications and domain specific services has to be
necessarily maintained and approved by python-dev. I'd go even further
and contend that's one of the issues where a rather large community
such as Pythons could grow up and set code review standards ( and I
mean *manual* code reviews of conscientous readers. I don't mean
cheesecake or up(down)moddings in Web 2.0 style, implementing the
"wisdom of the crowd" ). I can even live with Eggs and a not-so-common
code base but not with low quality.

 

[Paul Boddie]

Maybe that's one of two fixed points in the evolution of a programming
language? The other one might be an almost non-designed and small
language with a vast and flat library a la PHP and Zend. Apparently
even Scheme moves into the kitchen sink today with the new R6RS
specification.

My impression of PHP (before version 5), derived from anecdotes and
general criticism, is that both the language and the most promoted
libraries have accumulated features without much regard to how the end-
user experience works out. In contrast, it is said that Python has
been improved with more attention to the end-user experience (albeit
with limitations related to the main implementation and backwards
compatibility), with Python 3000 being the pinnacle of this user-
centric process. Regardless of whether Python 3000 really tidies up
the experience, it is notable that the promotional value of the
standard library has diminished, perhaps because the core developers
no longer feel that the language attracts embarrassing criticism which
is best answered by deflecting the critic to standard library
solutions.

Python is going to be the-right-thing with abandoning the print
statement or making lists a bit more monotyped with a type aware sort.
The worse-is-better philosophy on the other hand is indifferent
towards stylistic consistency and equipped with less nominalistic
pedantry ( "this is a list and therefore you only have to use it as a
list and not as a multiset..." ).

I think you've swum into the philosophical "deep end" on this
point. ;-) But of the different articles on the PythonWarts page I
mentioned, Mertz's criticisms (which include notes on sorting
heterogeneous collections) are certainly worth reading, partly because
they do highlight awkward-to-address end-user expectations whilst
being fairly modern criticisms. That's not to say that I agree with
everything he writes, although I have some sympathy with his opinions
on iterators vs. sequences and the current level of convenience in
this area.

This explains also the lack of interest into the std library which
will be reduced to CPython services and basic datatypes. But there are
also organizational issues and I don't even think that a lib that
provides applications and domain specific services has to be
necessarily maintained and approved by python-dev. I'd go even further
and contend that's one of the issues where a rather large community
such as Pythons could grow up and set code review standards ( and I
mean *manual* code reviews of conscientous readers. I don't mean
cheesecake or up(down)moddings in Web 2.0 style, implementing the
"wisdom of the crowd" ). I can even live with Eggs and a not-so-common
code base but not with low quality.

Once upon a time I wrote some thoughts down about marketing Python
where one considers a number of things as the "product" or "solution".
Certainly, in earlier times, adding stuff to the standard library was
a way of positioning Python as a solution to problems in particular
domains: if you needed to write a mail client, for example, Python
provided a working solution as standard that would potentially be
enough to persuade people to use Python for such a project. The belief
that modules should be included in the standard library is a
continuation of this "positioning" or advocacy-related sentiment, as
well as being an issue of convenience, of course.

As technical issues start to encourage other models for providing
solutions based on Python, one has to consider the social aspects of
such models. Where something in the standard library should have an
implicit stamp of approval, although opinions are divided on whether
some modules deserve their place, other models need to support notions
of approval, credibility, quality, and so on. And there we have
different approaches: repositories (optionally with rankings, noticing
that Ubuntu seems to be adding support for such things),
megaframeworks (where people effectively recommend a combination of
solutions), "heavy" distributions (with a selection of popular
packages in an enlarged standard library).

In my opinion, such wider work on promoting Python's usability is
possibly more beneficial to both potential and existing elements of
the community than merely polishing the language and hoping that
people are motivated to write great code because of the increased
elegance.

Paul