geremy condra writes:
> On Wed, Oct 28, 2009 at 12:34 PM, average <dreamingforw...@gmail.com> wrote:
> > [I wrote:]
> >> If Python3 were to have this feature it would make it worth
> >> migrating to
> >
> > Sorry that may have sounded more harsh than I expected. If I had more
> > resources,
> This is effectively the sandbox idea I proposed,
Um, guys? Python 3000 was a project involving fairly concentrated
effort by about a dozen senior, very skilled, developers plus many
others over a period of several (3 or 4?) years. The "sandbox" is
going to be played in by people without the resources to create such
an industrial-strength "code workshop," and as such is not going to be
given anywhere near the credibility that the py3k effort got. As
evidence of how difficult an effort like "Python 3000" is, consider:
where is Perl 6? There are hundreds, perhaps thousands, of developers
saying "we want Perl 6" but the resources aren't there to *finish* it.
On the other hand, "this feature" is already present in Python in
great generality. You just have to spell it
for x in container:
break
(or any of several other ways). The multiple spellings (of different
degrees of efficiency) and the lack of an obvious spelling are indeed
warts IMO, but "this feature would make Python 3 worth migrating to"
and "+5" are hard for me to understand except as extreme exaggeration.
The Python 3000 effort succeeded because the resources were sufficient
to the goal. Part of that is because some very powerful developers
found some itches they needed to scratch: Guido is clearly happy with
P3tL (Python 3 the Language), both its current state and the fact that
all that effort was devoted to it.
But now he (inter alia) wants to focus effort (mostly not his own ;-)
on P3tSL (Python 3 the Standard Library) which still needs substantial
cleanup though it's already very usable for many applications, and on
P3S3PA (Python 3 Supported 3rd Party Applications). The resources
available for language evolution have dried up; *you* who want more
language evolution are going to have to supply them.
OTOH, there are at present few attractive improvements. set.getany()
is an example of the kind of decidedly unattractive improvement
currently available. It has an efficient if not obvious spelling as
above; it has several less efficient but more transparent spellings as
have been posted several times. The *need* is not infinitesimal; some
good programmers have testified to being stumped by this one. But
it's not big, either. The *resources* required are surprisingly large:
although we already have a satisfactory implementation, about half of
this thread has been devoted to discussing the various names proposed,
and no conclusion reached in this thread or the previous one (of
similar length).
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
