Showing content from http://mail.python.org/pipermail/python-dev/attachments/20120609/700f5a24/attachment.html below:
<html style="direction: ltr;">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<style>body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;"
bidimailui-detected-decoding-type="UTF-8" bgcolor="#FFFFFF"
text="#000000">
On 8/06/2012 9:29 PM, Brett Cannon wrote:
<blockquote
cite="mid:CAP1=2W5DufnSrg90v0uQxfykhv=fagFM=2owUdoi-Ei6U4Euyg@mail.gmail.com"
type="cite"><br>
<br>
<div class="gmail_quote">On Fri, Jun 8, 2012 at 2:21 PM, <a
moz-do-not-send="true" href="mailto:fwierzbicki@gmail.com">fwierzbicki@gmail.com</a>
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:fwierzbicki@gmail.com" target="_blank">fwierzbicki@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, Jun 8, 2012 at 10:59 AM, Brett Cannon
<<a moz-do-not-send="true" href="mailto:brett@python.org">brett@python.org</a>>
wrote:<br>
> R. David already replied to this, but just to
reiterate: tests can always<br>
> get updated, and code that fixes a bug (and leaving a
file open can be<br>
> considered a bug) can also go in. It's just stuff like
code refactoring,<br>
> speed improvements, etc. that can't go into Python 2.7
at this point.<br>
</div>
Thanks for the clarification!<br>
<div class="im"><br>
> If/until the stdlib is made into its own repo, should
the various VMs<br>
> consider keeping a common Python 2.7 repo that contains
nothing but the<br>
> stdlib (or at least just modifications to those) so
they can modify in ways<br>
> that CPython can't accept because of compatibility
policy? You could keep it<br>
> on <a moz-do-not-send="true"
href="http://hg.python.org" target="_blank">hg.python.org</a>
(or wherever) and then all push to it. This might also be a<br>
> good way to share Python implementations of extension
modules for Python 2.7<br>
> instead of everyone maintaining there own for the next
few years (although I<br>
> think those modules should go into the stdlib directly
for Python 3 as<br>
> well). Basically this could be a test to see if
communication and<br>
> collaboration will be high enough among the other VMs
to bother with<br>
> breaking out the actual stdlib into its own repo or if
it would just be a<br>
> big waste of time.<br>
</div>
I'd be up for trying this. I don't think it's easy to fork a<br>
subdirectory of CPython though - right now I just keep an
unchanged<br>
copy of the 2.7 LIb in our repo (PyPy does the same, at least
the last<br>
time I checked).<br>
</blockquote>
<div><br>
</div>
<div>Looks like hg doesn't have support yet:Â <a
moz-do-not-send="true"
href="http://stackoverflow.com/questions/920355/how-do-i-clone-a-sub-folder-of-a-repository-in-mercurial">http://stackoverflow.com/questions/920355/how-do-i-clone-a-sub-folder-of-a-repository-in-mercurial</a>Â .</div>
<div>Â </div>
<div>The only sane option I can see then is to keep doing what
you and PyPy are doing and keep a copy of the stdlib, but now
you all simply share the repo instead of keeping your own
copies and possibly use subrepos to pull it into your own hg
repos.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> P.S. Do we need a python-implementations mailing list
or something for<br>
> discussing overall VM-related stuff among all VMs
instead of always bringing<br>
> this up on python-dev? E.g. I wish I had a place where
I could get all the<br>
> VM stakeholders' attention to make sure that importlib
as it stands in<br>
> Python 3.3 will skip trying to import Python bytecode
properly (or if the<br>
> VMs will simply provide their own setup function and
that won't be a worry).<br>
> And I would have no problem with keeping it like
python-committers in terms<br>
> of closed subscriptions, open archive in order to keep
the noise low.<br>
</div>
I think a python-implementations list would be a fantastic
idea - I<br>
sometimes miss multi-implementation discussions in python-dev,
or at<br>
least come in very late.<br>
</blockquote>
<div><br>
</div>
<div>If other people agree then I will get Barry to create it. </div>
</div>
</blockquote>
<p>I will follow a path of contributing the changes using
bugs.python.org. Suggested changes will be the minumum needed to
make the stdlib modules functional on pypy<br>
</p>
<p>Thanks,<br>
</p>
<p>Matti<br>
</p>
</body>
</html>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4