On 3/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On 10:22 pm, [EMAIL PROTECTED] wrote:
[snip]
> >I'm hoping Collin will continue his excellent work on 2to3. Hopefully
> >he'll get help from others in writing docs aimed at teaching the
> >c.l.py crowd how to use it and what to expect.
>
> I
Absolutely right. I'll withdraw the lightweight version. It's done
enough damage.
On 3/11/07, Andrew McNamara <[EMAIL PROTECTED]> wrote:
> >I wrote two versions of the dict views refactoring. One that turns
> >d.keys() into list(d.keys()) and d.iterkeys() into iter(d.keys()).
> >This one is pretty
>I wrote two versions of the dict views refactoring. One that turns
>d.keys() into list(d.keys()) and d.iterkeys() into iter(d.keys()).
>This one is pretty robust except if you have classes that emulate
>2.x-style dicts. But it generates ugly code. So I have a
>"light-weight" version that leaves d.
On 3/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On 10:22 pm, [EMAIL PROTECTED] wrote:
> >On 2/27/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >>2to3 should take great care _tell_ you when it fails. One concern I have
> >>is that the source translation may subtly alter the *semantic
On 10:22 pm, [EMAIL PROTECTED] wrote:
On 2/27/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
2to3 should take great care _tell_ you when it fails. One concern I
have is that the source translation may subtly alter the *semantics*
of unit test code, so that the tests are no longer effective a
On 2/27/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 2to3 should take great care _tell_ you when it fails. One concern I have is
> that the source translation may subtly alter the *semantics* of unit test
> code, so that the tests are no longer effective and do not provide adequate
> cove
On 3/5/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
> Thomas Wouters wrote:
>
> > developers and people who develop their own software. I would like to hear
> > from people who have concrete doubts about this upgrade path. I don't mean
>
> Disclaimer: I'm not involved in Py3k, and not even tried
Thomas Wouters wrote:
> developers and people who develop their own software. I would like to hear
> from people who have concrete doubts about this upgrade path. I don't mean
Disclaimer: I'm not involved in Py3k, and not even tried it once. And
don't know the details of the tool to "transform" P
On 2/28/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
[snip]
> 2to3 should take great care _tell_ you when it fails. One concern I have is
> that the
> source translation may subtly alter the *semantics* of unit test code, so
> that the tests
> are no longer effective and do not provide adequ
On Sun, 25 Feb 2007 13:12:51 -0800, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>I'm sending this to python-dev instead of python-3000 for two reasons: It's
>not about features to be added to Python 3.0, and it's not really
>about 3.0at all -- it's about
>2.6 and later. It's about how we get Python 2
Stephen J. Turnbull wrote:
> RKN = reverse Knuth numbering?
No, for RKN you'd have to start with 3141.5926... (an
infinite number of digits following) and drop one off
the end each time... although it would take rather a
long time to get to the final release then. :-(
--
Greg
___
Barry Warsaw writes:
> I said semi-jokingly that the first release of Py3k should be /
> literally/ called Python 3000. Then each successive stabilizing
> release should drop a zero -- e.g. Python 3000, then Python 300, then
> Python 30.
RKN = reverse Knuth numbering?
_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 25, 2007, at 3:49 PM, Neal Norwitz wrote:
> The time schedules in PEP 361 (2.6 release schedule) and what Guido
> has said for 3k (from what I remember) are roughly:
>
> April 2007 - 3.0 PEPs and features accepted/decided
> June 2007 - 3.0a1
Thomas Wouters wrote:
> One thing in particular I wonder about
> is the warning about mixing tabs and spaces. Should it be in category 2)
> (on by default) or 3) (still off by default, but part of -Wpy3k)?
For my part, it wouldn't bother me at all if you
turn it on by default any time you want.
On 2/25/07, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> On Sun, Feb 25, 2007 at 05:37:08PM -0600, Guido van Rossum wrote:
> > Right. To be honest, I consider the str/unicode unification a much
> > bigger project than the new I/O library.
>
> I was more concerned about IO because it would seem to
On Sun, Feb 25, 2007 at 05:37:08PM -0600, Guido van Rossum wrote:
> Right. To be honest, I consider the str/unicode unification a much
> bigger project than the new I/O library.
I was more concerned about IO because it would seem to require your
time for design work. The str/unicode work could be
On 2/25/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 2/25/07, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> > Any talk at PyCon regarding the new IO system? That looks like the
> > biggest piece of unfinished Py3k work.
>
> AFAIK, there hasn't been any work on the new IO system or str/unicode
Just the "it's not there yet" part :) There's some prototype code and email
conversations archived, but no recent work that I'm aware of.
On 2/25/07, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
Neal Norwitz <[EMAIL PROTECTED]> wrote:
> The time schedules in PEP 361 (2.6 release schedule) and wh
On 2/25/07, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > The time schedules in PEP 361 (2.6 release schedule) and what Guido
> > has said for 3k (from what I remember) are roughly:
> >
> > April 2007 - 3.0 PEPs and features accepted/decided
> > June 2
Neal Norwitz <[EMAIL PROTECTED]> wrote:
> The time schedules in PEP 361 (2.6 release schedule) and what Guido
> has said for 3k (from what I remember) are roughly:
>
> April 2007 - 3.0 PEPs and features accepted/decided
> June 2007 - 3.0a1 - basic (most) features implemented
Any talk at PyCon r
On 2/25/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
> It's about how we get Python 2.x to 3.0, and howmuch of 3.0 we put into 2.6
> and later.
I've also talked to a bunch of people at PyCon, including Thomas.
There seems to be much concern (rightfully so!) about the upgrade path
from 2.x to 3
I'm sending this to python-dev instead of python-3000 for two reasons: It's
not about features to be added to Python 3.0, and it's not really
about 3.0at all -- it's about
2.6 and later. It's about how we get Python 2.x to 3.0, and howmuch of
3.0we put into
2.6 and later.
So here at PyCon, Guido
22 matches
Mail list logo
