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

[Paul Boddie]

On 7 Sep, 06:19, Kay Schluehr <kay.schlu... at gmx.net> wrote:
> On Sep 6, 12:56 pm, Paul Boddie <p... at boddie.org.uk> wrote:
>
> > 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.

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