[Python-3000] Py3k release schedule worries

[Brett Cannon]

On 12/18/06, Guido van Rossum <guido at python.org> wrote:
>
> 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. :-)


Gotcha.

> 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.


OK, glad to have that cleared up.

> 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.


OK.  I will try to get it bootstrapped in then.

> 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?


Quaint.  I can live with that.

> > - 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?


I mis-spoke.  Tony Lownds has one but I didn't see a link in any of his
emails to the code.

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.


So code objects would grow a co_annotations that would be a tuple of strings
that stored what the annotations were as strings, with the last slot
reserved for returns.  Any parameter that didn't have an annotation would
have None assigned to it.  This means that this code::

  def fxn(a:int, b, c:str='hi') -> float: pass

would have a co_annotations of ``('int', None, 'str', float)``.  Keeping
everything as strings keeps it simple and minimizes any performance impact
from them being declared.  People can then easily write decorators that read
the tuple (or use signature objects) to type-check as desired.

Tony's implementation seems to actually fetch from globals what the
annotation specifies and I just don't think that is necessary and unneeded
overhead.  Then again, functions are only created once and extra overhead
could help discourage too much usage.  But using strings and None like this
cleanly solves the ambiguity issue of what value represents when no
annotation was set (object, type?).

> > 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.


Sounds good.  The only sticky point is whether we want to keep this
dichotomy of C/Python implementations ala pickle and StringIO going.  I
personally would rather choose one (Python or C) and then work on getting
the other to have the proper semantics.  If we choose the C version we can
stick the Python versions into lib-old or something so that if alternative
Python implementations want to keep them alive and up-to-date they can for
their own usage but the burden is taken off of us.

> 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.


OK.  I can also bug you at PyCon about it (assuming you are not doing a PEP
parade this year) and spend my sprint time on these two PEPs.

> 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?


Yep.  As in it could go into Py3K and/or Python 2.x.

> 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.


That's what I mean.  I don't want to introduce new features, just maybe
change stuff like saying that built-in modules are handles by a meta_path
entry instead of monolithically by __import__ itself, etc.  Maybe even
changing its signature (don't know if globals and locals are really needed
since you really only need __name__ and __path__ of the caller), etc.  But
that is a PEP topic and does not need to be worried about right now.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20061218/2a40d689/attachment-0001.htm