From: Carl Banks on
On Jan 27, 2:19 pm, exar...(a)twistedmatrix.com wrote:
> On 10:07 pm, pavlovevide...(a)gmail.com wrote:
> >Last I heard, don't remember where, the plan was for Python 2.7 to be
> >the last version in the Python 2 line.  If that's true, Python 3
> >acceptance is further along at this point than anticipated, since they
> >originally thought they might have to go up to 2.9.
>
> This assumes that the decision to stop making new 2.x releases is based
> on Python 3 adoption, rather than on something else.

I should have said, "If anything...".


Carl Banks
From: Paul Rubin on
Steven D'Aprano <steven(a)REMOVE.THIS.cybersource.com.au> writes:
> 6. The code for Python 3 was handed down to Guido from the Heavens,
> carved into stone tablets by the Gods themselves.

That is heresy. The direction was up, not down.
From: Steven D'Aprano on
On Wed, 27 Jan 2010 16:25:46 -0500, Benjamin Kaplan wrote:

> When Python 2.6 came out, Jython was still on 2.2. The difference
> between 2.2 and 2.6 is almost as big of a difference as between 2.6 and
> 3.0. In that time, you had the introduction of the boolean type,
> generators, list comprehensions, the addition of the "yield" and "with"
> keywords, universal newline support, and decorators in addition to the
> large number of changes to the standard library such as the introduction
> of the subprocess module.

THANK YOU Benjamin for injecting this note of sanity into the discussion.

I believe that, with the possible exception of the change from byte
strings to unicode strings, virtually *all* the hoo-har over Python 3 is
simply due to the tactical mistake of Guido and the Python Dev team of
*calling* Python 3 a backward incompatible release. Python has had
previous major changes in the past (e.g. 1.5 to 2.0 and 2.1 to 2.2) and
hardly anyone made a complaint.

Certainly the move from 2.x to 3.x is a big move. If you have to support
both series simultaneously, I don't envy your job, but if CherryPy can do
it, so can others. But it's not qualitatively different from supporting
(say) 2.4 through 2.6. Targeting multiple versions is always a PITA.

I also find it telling that perhaps the biggest change of all, the one
from byte strings to unicode, hardly rates a mention from the skeptics
and haters. Instead we get rants about how division behaves differently
(forgetting that "from __future__ import division" has worked since at
least 2.4 and possibly older) and complaints that print is different.



--
Steven
From: alex23 on
Terry Reedy <tjre...(a)udel.edu> wrote:
> Actually, Unladen Swallow is now targeted at 3.1; its developers have
> conservatively proposed its integration in CPython 3.3. I would not be
> completely shocked if it happens in 3.2.

Why do I feel like there's less of an onus on Unladen Swallow to
_actually prove itself in substantial real world usage_ before
integration into CPython than there is on even the smallest of modules
for inclusion in the standard library?

Are we really expected to just ditch everything we know about
CPython's performance characteristics just for some questionable and
possibly uneven gains?

I've been a big supporter of Py3 from the beginning, but this repeated
claim of US becoming the mainline interpreter for 3.x pretty much
kills dead a lot of my interest. What am I not seeing amidst the high
memory usage and variable performance results of US's _custom-made_
benchmarks? Doesn't that fact alone worry anyone else? Or that LLVM is
listed as only having "partial support" with non-Cygwin x86 Windows?

Yes, I'd _love_ Python to be faster, who wouldn't? But I'm not seeing
the evidence here to support the almost unbridled eagerness that's
being demonstrated.

From: Steven D'Aprano on
On Wed, 27 Jan 2010 16:28:08 -0800, Paul Rubin wrote:

> Steven D'Aprano <steven(a)REMOVE.THIS.cybersource.com.au> writes:
>> 6. The code for Python 3 was handed down to Guido from the Heavens,
>> carved into stone tablets by the Gods themselves.
>
> That is heresy. The direction was up, not down.


SPLITTER!!!



--
Steven
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Prev: Ad hoc lists vs ad hoc tuples
Next: Python and Ruby