<br><br><div><span class="gmail_quote">On 12/18/06, <b class="gmail_sendername">Guido van Rossum</b> <<a href="mailto:guido@python.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">guido@python.org
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 12/18/06, Brett Cannon <<a href="mailto:brett@python.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">brett@python.org</a>> wrote:<br>> I always wondered about that due date and when you really wanted to cut an
<br>> alpha.<br><br>Despite what the PEP says I've always *thought* of it as "early 2007"
<br>which I can stretch to June but not much beyond. :-)</blockquote><div><br>Gotcha. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> I know the reason I didn't jump in on the refactoring tool is that a) I was<br>> wondering how Jeremy's tool fit into all of this (if at all),<br><br>I think Jeremy's version is de-facto dead. I discussed the two
<br>
approaches briefly with him, when my version was about as lame as his.<br>I never could get his version to produce valid output even from the<br>example checked in; it seems to work for him and only for him. When I<br>explained how I am doing it he seemed to agree that it's better to get
<br>the tokens and the tree from the same parser and in the same parsing<br>run -- that approach just didn't appear possible to him because he<br>wasn't aware of (or had forgotten about) the pgen reimplementation in<br>Python donated by Elemental, that is the crucial centerpiece of my
<br>version.</blockquote><div><br>OK, glad to have that cleared up. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> b) I am busy
<br>> with the import rewrite, c) my laptop is *still* in the shop and thus I<br>> can't hack at home, and d) it doesn't interest me as much as other things I<br>> want to do for Py3K.<br><br>Fair enough for sample of one. While I didn't mention the import
<br>rewrite, I hope that it will land in Py3k.</blockquote><div><br>OK. I will try to get it bootstrapped in then. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> A Python pie-in-the-sky list (python-ideas?) seems reasonable. Let's<br>> python-dev focus on maintaining the current code, python-3000 on<br>> Py3K-specific work, and the ideas list to be where new ideas are vetted out
<br>> and congealed into a PEP to bring to either python-3000 or python-dev.<br><br><a href="mailto:py-in-the-sky@python.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">py-in-the-sky@python.org
</a> anyone?</blockquote><div><br>Quaint. I can live with that. <br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> > - optional signature annotations (but without type checking<br>> > connotations);
e.g. ``def foo(a: 42) -> "hello kitty": pass'' should<br>> > be fine; see my Artima blogs<br>><br>> I have been thinking about this one, especially after the discussions of the<br>> patch floating around that has an initial implementation. I was planning on
<br>> tackling this at some point so it was nice and simple (just store strings<br>> instead of actual types so it truly just documentation initially) and tied<br>> into my signature PEP.<br><br>Oops, I must have missed that there is a patch. Where?
</blockquote><div><br>I mis-spoke. Tony Lownds has one but I didn't see a link in any of his emails to the code. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
When you say "just store strings" do you mean that the implementation<br>would be limited to strings or just that you would only use it to<br>store per-argument docstrings? The latter is fine with me; the former
<br>seems an unnecessary restriction.</blockquote><div><br>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::
<br><br> def fxn(a:int, b, c:str='hi') -> float: pass<br><br>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.
<br><br>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?).
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> > Perhaps the most controversial issue that I'd like to tackle is a<br>
> > standard library reorganization. This is so controversial that I don't<br>> > even know where to begin. Maybe the refactoring tool will be able to
<br>> > help and can automatically convert imports using old locations to<br>> > imports using new locations? Then if the new locations are also made<br>> > available in Python 2.6, we'd even have an upgrade path. Who wants to
<br>> > help out here? There's a huge amount of work and if it is left to me<br>> > it won't get done.<br>><br>> Well, I have tried to move this forward before and it always just leads to a<br>> huge explosion of ideas and feelings and just doesn't get anywhere. I am
<br>> willing to be the guy to don the flame suit once again on this topic and try<br>> to get this PEP written for strategy for renaming, reorganizing, and<br>> deprecating modules.<br>><br>> But I will probably need some general guidance from what you are looking for
<br>> in terms of scope (e.g., if I remember correctly you don't want a 'py'<br>> top-level namespace and you didn't like the idea of having like a 'net'<br>> package, etc.) and depth (does the renaming extend to methods?).
<br><br>Well, what do you think of my pronouncement in response to Thomas's<br>mail (just rename a bunch of things that don't conform to our own<br>naming standard)? That should limit the discussion to what's the best<br>
name for StringIO etc.</blockquote><div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> I am definitely willing to commit to PEP 352 (new-style exceptions) and PEP
<br>> 362 (signature PEP, but still needs a pronouncement).<br><br>I promise to look at that next.</blockquote><div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> After that I am up
<br>> for helping with the library re-org and probably with the type annotations<br>> stuff. I am considering my import work as implementation-specific and thus<br><br>Did you mean implementation-independent?</blockquote>
<div><br>Yep. As in it could go into Py3K and/or Python 2.x. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> can go in at almost any point (assuming backwards-compatibility issues are<br>> not considered too horrible or performance is within reason) and thus not<br>> necessarily time critical (unless you want to force it into Py3K to specify
<br>> "new" semantics), in which case I would shift that up in priority.<br><br>I don't want new semantics for import, I just want the existing<br>semantics cleaned up and more easily tweaked through subclassing.
</blockquote><div><br>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.
<br><br>-Brett</div></div>