[Python-3000] Py3k release schedule worries

[Guido van Rossum]

On 12/18/06, Brett Cannon <brett at python.org> wrote:
> I always wondered about that due date and when you really wanted to cut an
> alpha.

Despite what the PEP says I've always *thought* of it as "early 2007"
which I can stretch to June but not much beyond. :-)

> I know the reason I didn't jump in on the refactoring tool is that a) I was
> wondering how Jeremy's tool fit into all of this (if at all),

I think Jeremy's version is de-facto dead. I discussed the two
approaches briefly with him, when my version was about as lame as his.
I never could get his version to produce valid output even from the
example checked in; it seems to work for him and only for him. When I
explained how I am doing it he seemed to agree that it's better to get
the tokens and the tree from the same parser and in the same parsing
run -- that approach just didn't appear possible to him because he
wasn't aware of (or had forgotten about) the pgen reimplementation in
Python donated by Elemental, that is the crucial centerpiece of my
version.

> b) I am busy
> with the import rewrite, c) my laptop is *still* in the shop and thus I
> can't hack at home, and d) it doesn't interest me as much as other things I
> want to do for Py3K.

Fair enough for sample of one. While I didn't mention the import
rewrite, I hope that it will land in Py3k.

> A Python pie-in-the-sky list (python-ideas?) seems reasonable.  Let's
> python-dev focus on maintaining the current code, python-3000 on
> Py3K-specific work, and the ideas list to be where new ideas are vetted out
> and congealed into a PEP to bring to either python-3000 or python-dev.

py-in-the-sky at python.org anyone?

> > - optional signature annotations (but without type checking
> > connotations); e.g. ``def foo(a: 42) -> "hello kitty": pass'' should
> > be fine; see my Artima blogs
>
> I have been thinking about this one, especially after the discussions of the
> patch floating around that has an initial implementation.  I was planning on
> tackling this at some point so it was nice and simple (just store strings
> instead of actual types so it truly just documentation initially) and tied
> into my signature PEP.

Oops, I must have missed that there is a patch. Where?

When you say "just store strings" do you mean that the implementation
would be limited to strings or just that you would only use it to
store per-argument docstrings? The latter is fine with me; the former
seems an unnecessary restriction.

> > Perhaps the most controversial issue that I'd like to tackle is a
> > standard library reorganization. This is so controversial that I don't
> > even know where to begin. Maybe the refactoring tool will be able to
> > help and can automatically convert imports using old locations to
> > imports using new locations? Then if the new locations are also made
> > available in Python 2.6, we'd even have an upgrade path. Who wants to
> > help out here? There's a huge amount of work and if it is left to me
> > it won't get done.
>
> Well, I have tried to move this forward before and it always just leads to a
> huge explosion of ideas and feelings and just doesn't get anywhere.  I am
> willing to be the guy to don the flame suit once again on this topic and try
> to get this PEP written for strategy for renaming, reorganizing, and
> deprecating modules.
>
> But I will probably need some general guidance from what you are looking for
> in terms of scope (e.g., if I remember correctly you don't want a 'py'
> top-level namespace and you didn't like the idea of having like a 'net'
> package, etc.) and depth (does the renaming extend to methods?).

Well, what do you think of my pronouncement in response to Thomas's
mail (just rename a bunch of things that don't conform to our own
naming standard)? That should limit the discussion to what's the best
name for StringIO etc.

> I am definitely willing to commit to PEP 352 (new-style exceptions) and PEP
> 362 (signature PEP, but still needs a pronouncement).

I promise to look at that next.

> After that I am up
> for helping with the library re-org and probably with the type annotations
> stuff.  I am considering my import work as implementation-specific and thus

Did you mean implementation-independent?

> can go in at almost any point (assuming backwards-compatibility issues are
> not considered too horrible or performance is within reason) and thus not
> necessarily time critical (unless you want to force it into Py3K to specify
> "new" semantics), in which case I would shift that up in priority.

I don't want new semantics for import, I just want the existing
semantics cleaned up and more easily tweaked through subclassing.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)