<p dir="ltr"><br>
On Apr 14, 2014 2:42 PM, "Terry Reedy" <<a href="mailto:tjreedy@udel.edu">tjreedy@udel.edu</a>> wrote:<br>
><br>
> On 4/14/2014 1:19 PM, Guido van Rossum wrote:<br>
>><br>
>> Some quick thoughts:<br>
>><br>
>> - I'd prefer a name that plays on 2 and 3, not 2 and 8. :-)<br>
>><br>
>> - Are you sure this isn't better directed to python-ideas first? Most<br>
>> ideas have to prove their worth in that list before python-dev will give<br>
>> them the light of day.<br>
>><br>
>> - When it comes to purely syntactic issues (e.g. "except x, y:") a<br>
>> linter or some other separate tool can handle this well (heck, you can<br>
>> build it into an import hook probably :-).<br>
>><br>
>> - When it's about backported modules, a sumo distribution is probably<br>
>> the way to go; when it's about renamed stdlib modules, six (perhaps an<br>
>> extended version) should cover you.<br>
>><br>
>> - Regarding warning about the changed dict API, I wonder how you plan to<br>
>> implement that if you allow passing dict object back and forth between<br>
>> code that has opted in to single-source and code that hasn't yet. Please<br>
>> think through some specific examples before responding.<br>
>><br>
>> - But the biggest issue is of course bytes vs. text. You would have to<br>
>> first do a careful analysis of the *whole* problem before you can even<br>
>> think about proposing a solution. Too many people think their is an easy<br>
>> solution for this; but almost everybody is focused on only part of the<br>
>> problem (the part that causes them immediate pain) without realizing<br>
>> that other people's pain may be different.<br>
>><br>
>> - As far as your assertion that it would have to come from python-dev<br>
>> because nobody outside is going to tackle it, I think it's the opposite:<br>
>> the core developers would prefer not to have to deal with this, while<br>
>> some folks outside the inner circles will not be discouraged by our<br>
>> opinions (e.g. Stackless is working on "Stackless 2.8").<br>
>><br>
>> - Regarding open source projects having a reputation of "not taking<br>
>> contributions", I would guess that this is usually about those<br>
>> "contributions" violating the most basic rules of the project (and I<br>
>> don't mean the coding style). I do want to discourage discussions with<br>
><br>
><br>
> Did you mean 'don't want to discourage'?<br></p>
<p dir="ltr">Yes. Sorry. Pylon brain fry...<br></p>
<p dir="ltr">>> users like the company you referred to, but I think it would be much<br>
>> more useful if they laid out their problems for us instead of expecting<br>
>> they can buy acceptance for a "solution" they develop in-house. We could<br>
>> then hopefully have a productive dialog over many months where we<br>
>> iterate over possible approaches that could be acceptable both to Python<br>
>> and to the customer. But it will take a significant investment of time<br>
>> on both sides -- there is no shortcut. And it's not a particularly<br>
>> interesting problem (for most people) to work on -- things like<br>
>> designing a notation for optional type declarations are always much more<br>
>> fun. :-)<br>
>><br>
>><br>
>><br>
>><br>
>> On Mon, Apr 14, 2014 at 11:32 AM, Steve Dower <<a href="mailto:Steve.Dower@microsoft.com">Steve.Dower@microsoft.com</a><br>
>> <mailto:<a href="mailto:Steve.Dower@microsoft.com">Steve.Dower@microsoft.com</a>>> wrote:<br>
>><br>
>><br>
>> Just in case there's anyone out there who isn't yet sick of<br>
>> discussing how to proceed with Python 2.7, I have some more inputs<br>
>> to contribute.<br>
>><br>
>> To put it up front, I'm totally against "CPython 2.8" ever becoming<br>
>> a real thing. Anything that comes out should be seen as a migration<br>
>> path, not an upgrade path. I'll also admit I'm not heavily invested<br>
>> in working on it myself, but I had a number of conversations during<br>
>> PyCon (as well as being at the language summit) that puts me in a<br>
>> position to share the ideas and concerns that have been raised.<br>
>><br>
>> The main trigger was a conversation I had with two employees of a<br>
>> very large bank that has about 3000 Python users (not developers -<br>
>> mostly financial analysts) and 16 million lines of code running on<br>
>> 2.7. They are keen to migrate to 3.x but cannot afford to stop work<br>
>> entirely while their code is updated. (There was much more to the<br>
>> conversation than I'm relating here - I'm keeping to the directly<br>
>> relevant bits.)<br>
>><br>
>> In describing the approach they'd like to take, they made me realise<br>
>> that there is definitely a place for a Python that is different but<br>
>> mostly compatible with 2.7, in a way that 2.7.x could not be. For<br>
>> the sake of having a name, I'll refer to this as "Python 2migr8"<br>
>> (pronounced "to migrate" :) ).<br>
>><br>
>> The two important components of Python 2migr8 would be the ability<br>
>> to disable 2.7-only features, and to do so on a module-by-module basis.<br>
>><br>
>> My best idea so far would be to have a magic comment (to ensure 2.7<br>
>> compatibility better than a "from __future__ ...") near the top of<br>
>> the file that marks that file as "must straddle 2.7 and 3.3". Adding<br>
>> this comment causes (for example) the parser to treat "except x, y"<br>
>> as a syntax error in this file, forces "from __future__ import ...",<br>
>> hides "dict.iterkeys", undefines "basestring", etc., but only for<br>
>> this file. (I haven't thought through all the possibilities or<br>
>> implications - Eric Snow said he was going to sprint on this<br>
>> today/tomorrow, so he'll soon have a better idea just what can be done.)<br>
>><br>
>> In effect, 2migr8 would be the version that *only* supports<br>
>> "single-source" files. This allows large code bases to progressively<br>
>> migrate modules from 2.x to single-source while continuing to run<br>
>> against Python 2.7. As files are updated, they are marked as being<br>
>> single-source. When all files have this marker, it should be<br>
>> possible to flip the switch and run with Python 3.3 or later.<br>
>><br>
>> You could also think of this as enabling "-3 --warnings-as-errors"<br>
>> for individual modules, though since the user has already opted in<br>
>> to 2migr8, it isn't unreasonable to make more significant changes,<br>
>> like having dict.keys returning a list that warns if it is mutated.<br>
>> This sort of warning can only really be done by changing the<br>
>> interpreter - static analysis just can't catch everything - and only<br>
>> when users accept a potential performance hit and low probability of<br>
>> breakage when they move to 2migr8 (followed by a not-quite-as-low<br>
>> probability of breaking when they eventually move from 2migr8 to<br>
>> 3.x, but it's still better than guaranteed breakage).<br>
>><br>
>> As a fork, it would also be possible to bundle the modules that have<br>
>> been backported, and possibly also to disallow importing deprecated<br>
>> stdlib modules when 2.7 functionality is disabled. As I said, I<br>
>> haven't thought through all the possibilities, but the general idea<br>
>> is to take 2.7 and *remove* features so it becomes easier to migrate.<br>
>><br>
>> Where does python-dev come in? Obviously this is where a fork like<br>
>> this would have to start - there has been such strong and public<br>
>> opposition to any significant changes like this that you'd be hard<br>
>> pressed to find someone willing to start and promote it from<br>
>> outside. There is also a good opportunity to make a start and<br>
>> directly invite those using it to contribute the rules or warnings<br>
>> that they need - the 3000 Python "users" I mentioned earlier are<br>
>> backed by a team of true developers who are more than capable of<br>
>> contributing, and this would be a great opportunity to directly<br>
>> invite them. However unfair and incorrect it may be, there is a<br>
>> perception in some businesses that open-source projects do not want<br>
>> contributions from them. I invited more than one business to have<br>
>> someone join python-dev and get involved during PyCon, and I heard<br>
>> that others did the same - it may not be at the level of employing a<br>
>> core developer full time, but it's the starting point that some<br>
>> companies will ne<br>
>> ed to be able to become comfortable with employing a core dev.<br>
>><br>
>> I'm not pretending to have a full plan on how this will work. I was<br>
>> privileged to have some private conversations during PyCon that are<br>
>> directly relevant, so I'm bringing it here to promote the<br>
>> discussion. Thanks to everyone I had a chance to chat to, and to<br>
>> everyone generally for a great PyCon.<br>
>><br>
>> Cheers,<br>
>> Steve<br>
>><br>
>><br>
>> _______________________________________________<br>
>> Python-Dev mailing list<br>
>> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a> <mailto:<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a>><br>
>><br>
>> <a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
>> Unsubscribe:<br>
>> <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org">https://mail.python.org/mailman/options/python-dev/guido%40python.org</a><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> --Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a> <<a href="http://python.org/~guido">http://python.org/~guido</a>>)<br>
>><br>
>><br>
><br>
><br>
> -- <br>
> Terry Jan Reedy<br>
><br>
><br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org">https://mail.python.org/mailman/options/python-dev/guido%40python.org</a><br>
</p>