[python-committers] clinic churn after beta2
Hello, Does it really make sense to introduce large amounts of code churn after the release of 3.4 beta2? It started innocently enough, but now it seems that the whole implementation is being reconsidered (Antoine's email to pydev). This doesn't look like something we should be doing so late in the release process. Are we really that much in need of convert-to-clinic *now*? Eli ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] clinic churn after beta2
2014/1/7 Eli Bendersky : > Are we really that much in need of convert-to-clinic *now*? Why not creating the 3.4 branch after the beta1 and develop Python 3.5 in default during the stabilisation process of Python 3.4? It's like many other softwares are developed. Only bugfixes would be accepted in the branch 3.4, as we do currently with 3.3 branch. Victor ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] clinic churn after beta2
On Tue, Jan 7, 2014 at 1:26 PM, Victor Stinner wrote: > 2014/1/7 Eli Bendersky : > > Are we really that much in need of convert-to-clinic *now*? > > Why not creating the 3.4 branch after the beta1 and develop Python 3.5 > in default during the stabilisation process of Python 3.4? It's like > many other softwares are developed. > > Only bugfixes would be accepted in the branch 3.4, as we do currently > with 3.3 branch. > > I asked this exact question a few weeks ago, but got the answer that this is the way Python does it. Fair enough, but huge amount of churn generated by a not-yet-decided-how-it-should-work Argument Clinic is really unrelated and totally out of place between beta2 and the final release of a major Python version. Eli ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] clinic churn after beta2
On Tue, Jan 7, 2014 at 1:18 PM, Eli Bendersky wrote: > Hello, > > Does it really make sense to introduce large amounts of code churn after > the release of 3.4 beta2? It started innocently enough, but now it seems > that the whole implementation is being reconsidered (Antoine's email to > pydev). This doesn't look like something we should be doing so late in the > release process. > I wouldn't call that a whole implementation being reconsidered. People are just bike shedding over which wall to paint first. The color has already been established. Besides, Larry is both the release manager for 3.4 and argument clinic proponent. If we need a beta3 instead of an rc1 next, that is up to him. :) I'm not weighing in on the pydev thread despite having opinions because it just doesn't matter to me in the end. I'd just be adding noise and am happy to accept anything so long as argument clinic does stay in for 3.4. > Are we really that much in need of convert-to-clinic *now*? > It'll never happen otherwise. -gps ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] clinic churn after beta2
On mar., 2014-01-07 at 13:18 -0800, Eli Bendersky wrote: > Hello, > > Does it really make sense to introduce large amounts of code churn > after the release of 3.4 beta2? It started innocently enough, but now > it seems that the whole implementation is being reconsidered > (Antoine's email to pydev). This doesn't look like something we should > be doing so late in the release process. > > Are we really that much in need of convert-to-clinic *now*? I guess the question is: are there large enough benefits to be reaped for risking the release (a bit)? There's no question Argument Clinic can bring interesting benefits, it's just a question of timing. Regards Antoine. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] clinic churn after beta2
On Jan 7, 2014, at 1:33 PM, Antoine Pitrou wrote: > On mar., 2014-01-07 at 13:18 -0800, Eli Bendersky wrote: >> Hello, >> >> Does it really make sense to introduce large amounts of code churn >> after the release of 3.4 beta2? It started innocently enough, but now >> it seems that the whole implementation is being reconsidered >> (Antoine's email to pydev). This doesn't look like something we should >> be doing so late in the release process. >> >> Are we really that much in need of convert-to-clinic *now*? > > I guess the question is: are there large enough benefits to be reaped > for risking the release (a bit)? > There's no question Argument Clinic can bring interesting benefits, it's > just a question of timing. Let me play the devil’s advocate here: how much do we risk in future maintainability costs if we move to Argument Clinic in Python 3.5 and leave large parts of Python 3.4 uncovered by it? I mean that we can get some ugly diffs between code using Argument Clinic and manual argument parsing. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] clinic churn after beta2
On 01/07/2014 01:18 PM, Eli Bendersky wrote: Does it really make sense to introduce large amounts of code churn after the release of 3.4 beta2? It started innocently enough, but now it seems that the whole implementation is being reconsidered (Antoine's email to pydev). This doesn't look like something we should be doing so late in the release process. Are we really that much in need of convert-to-clinic *now*? Making help more helpful is a huge win, and the time to hammer out the bugs in AC is definitely now. -- ~Ethan~ ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] clinic churn after beta2
On Tue, Jan 7, 2014 at 4:31 PM, Gregory P. Smith wrote: > > On Tue, Jan 7, 2014 at 1:18 PM, Eli Bendersky wrote: > >> Hello, >> >> Does it really make sense to introduce large amounts of code churn after >> the release of 3.4 beta2? It started innocently enough, but now it seems >> that the whole implementation is being reconsidered (Antoine's email to >> pydev). This doesn't look like something we should be doing so late in the >> release process. >> > > I wouldn't call that a whole implementation being reconsidered. People are > just bike shedding over which wall to paint first. The color has already > been established. > Agreed. > > Besides, Larry is both the release manager for 3.4 and argument clinic > proponent. If we need a beta3 instead of an rc1 next, that is up to him. :) > Exactly. It also helps that this is not meant to change semantics (beyond better help() ATM) so unit tests + compiler checks should be enough to catch any major issues that Argument Clinic might cause. > > I'm not weighing in on the pydev thread despite having opinions because it > just doesn't matter to me in the end. I'd just be adding noise and am happy > to accept anything so long as argument clinic does stay in for 3.4. > > >> Are we really that much in need of convert-to-clinic *now*? >> > > It'll never happen otherwise. > I see no reason not to get it done now. I would honestly say we should push the release to see it finished so we don't end up with some C code converted and not others. Might as well get all extension code to have defined signatures than only some at this point. -Brett > > -gps > > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] clinic churn after beta2
вівторок, 07-січ-2014 13:42:29 Łukasz Langa написано: > Let me play the devil’s advocate here: how much do we risk in future > maintainability costs if we move to Argument Clinic in Python 3.5 and > leave large parts of Python 3.4 uncovered by it? > > I mean that we can get some ugly diffs between code using Argument Clinic > and manual argument parsing. As between clinicalized 3.4 and 3.3 or 2.7? ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] clinic churn after beta2
On Tue, Jan 7, 2014 at 1:33 PM, Antoine Pitrou wrote: > On mar., 2014-01-07 at 13:18 -0800, Eli Bendersky wrote: > > Hello, > > > > Does it really make sense to introduce large amounts of code churn > > after the release of 3.4 beta2? It started innocently enough, but now > > it seems that the whole implementation is being reconsidered > > (Antoine's email to pydev). This doesn't look like something we should > > be doing so late in the release process. > > > > Are we really that much in need of convert-to-clinic *now*? > > I guess the question is: are there large enough benefits to be reaped > for risking the release (a bit)? > There's no question Argument Clinic can bring interesting benefits, it's > just a question of timing. > Just to be clear, this is exactly what I mean. I'm not saying AC is not worth it; I'm questioning the timing. Eli ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] clinic churn after beta2
On Tue, Jan 07, 2014 at 02:37:22PM -0800, Eli Bendersky wrote: > Just to be clear, this is exactly what I mean. I'm not saying AC is not > worth it; I'm questioning the timing. Agreed; let's try to avoid far-ranging sets of changes so late in the beta cycle. If we want to send 3.4 back to alpha and implement some form of string-formatting changes and Argument Clinic, that would be fine, though it might mean Ubuntu and other Linux distros might have to ship with 3.3 again because 3.4 wasn't done in time. --amk ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] clinic churn after beta2
On 8 Jan 2014 07:11, "A.M. Kuchling" wrote: > > On Tue, Jan 07, 2014 at 02:37:22PM -0800, Eli Bendersky wrote: > > Just to be clear, this is exactly what I mean. I'm not saying AC is not > > worth it; I'm questioning the timing. > > Agreed; let's try to avoid far-ranging sets of changes so late in the > beta cycle. > > If we want to send 3.4 back to alpha and implement some form of > string-formatting changes and Argument Clinic, that would be fine, > though it might mean Ubuntu and other Linux distros might have to ship > with 3.3 again because 3.4 wasn't done in time. The bytes formatting change is right out. It likely requires the use of the 3.3 or 2.7 bytestring formatting code as the basis and should be feasible to implement and publish as a function in a cross-version PyPI library before locking in the syntax and semantics for Python 3.5, so I see zero justification for delaying Python 3.4 on that basis. It's relevant to the question of encouraging migrations from Python 2 (as current Python developers are used to having a feature like that available), but is not especially significant in terms of encouraging *new* development in Python 3 (since it's a relatively obscure use case with multiple alternative approaches available). Back on topic for the thread, the argument clinic conversions seem unlikely to introduce *subtle* bugs that the test suite misses, so it doesn't bother me that Larry is encouraging such changes as part of the beta cycle. If an extra beta or release candidate ends being needed, so be it, but I'm happy to leave that call to Larry as release manager. Cheers, Nick. > --amk > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] clinic churn after beta2
On Tue, Jan 7, 2014, at 04:29 PM, Nick Coghlan wrote: > On 8 Jan 2014 07:11, "A.M. Kuchling" wrote: > > > > On Tue, Jan 07, 2014 at 02:37:22PM -0800, Eli Bendersky wrote: > > > Just to be clear, this is exactly what I mean. I'm not saying AC is not > > > worth it; I'm questioning the timing. > > > > Agreed; let's try to avoid far-ranging sets of changes so late in the > > beta cycle. > > > > If we want to send 3.4 back to alpha and implement some form of > > string-formatting changes and Argument Clinic, that would be fine, > > though it might mean Ubuntu and other Linux distros might have to ship > > with 3.3 again because 3.4 wasn't done in time. > > The bytes formatting change is right out. It likely requires the use of > the > 3.3 or 2.7 bytestring formatting code as the basis and should be feasible > to implement and publish as a function in a cross-version PyPI library > before locking in the syntax and semantics for Python 3.5, so I see zero > justification for delaying Python 3.4 on that basis. It's relevant to the > question of encouraging migrations from Python 2 (as current Python > developers are used to having a feature like that available), but is not > especially significant in terms of encouraging *new* development in > Python > 3 (since it's a relatively obscure use case with multiple alternative > approaches available). A PyPI module is not so great because you'll have to change every formatting operation to use a function from a module rather than the % operator or the format method. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] clinic churn after beta2
On 1/7/2014 7:33 PM, Benjamin Peterson wrote: > A PyPI module is not so great because you'll have to change every > formatting operation to use a function from a module rather than the % > operator or the format method. I think this is the crux of the issue. Are we trying to say "porting your existing code will be easier", or "change your existing code to this new library, and we'll provide the library on 2.x and 3.y" (for some values of x and y). I think the former is the right way to go, but I also think if we do that we should shoot for 3.4, and this would necessitate a delay in 3.4. Providing this feature for 3.5 might be too late for the target audience of code porters. Eric. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] clinic churn after beta2
On 01/07/2014 03:10 PM, A.M. Kuchling wrote: On Tue, Jan 07, 2014 at 02:37:22PM -0800, Eli Bendersky wrote: Just to be clear, this is exactly what I mean. I'm not saying AC is not worth it; I'm questioning the timing. Agreed; let's try to avoid far-ranging sets of changes so late in the beta cycle. If we want to send 3.4 back to alpha and implement some form of string-formatting changes and Argument Clinic, that would be fine, though it might mean Ubuntu and other Linux distros might have to ship with 3.3 again because 3.4 wasn't done in time. I hadn't considered slipping the release, but that does seem like an entirely sane idea. However, I'm not proposing slipping back to alpha so we can add the cause-celebre-of-the-week bytes formatting stuff, and we don't need to slip all the way back to alpha for Argument Clinic. A third beta seems entirely reasonable though. Let's try the derby for a couple of days and see how we feel. //arry/ ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] clinic churn after beta2
On Tue, Jan 7, 2014 at 4:58 PM, Larry Hastings wrote: > On 01/07/2014 03:10 PM, A.M. Kuchling wrote: > > On Tue, Jan 07, 2014 at 02:37:22PM -0800, Eli Bendersky wrote: > > Just to be clear, this is exactly what I mean. I'm not saying AC is not > worth it; I'm questioning the timing. > > Agreed; let's try to avoid far-ranging sets of changes so late in the > beta cycle. > > If we want to send 3.4 back to alpha and implement some form of > string-formatting changes and Argument Clinic, that would be fine, > though it might mean Ubuntu and other Linux distros might have to ship > with 3.3 again because 3.4 wasn't done in time. > > > I hadn't considered slipping the release, but that does seem like an > entirely sane idea. However, I'm not proposing slipping back to alpha so > we can add the cause-celebre-of-the-week bytes formatting stuff, and we > don't need to slip all the way back to alpha for Argument Clinic. A third > beta seems entirely reasonable though. Let's try the derby for a couple of > days and see how we feel. > > +1 ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] clinic churn after beta2
On 8 Jan 2014 08:44, "Eric V. Smith" wrote: > > On 1/7/2014 7:33 PM, Benjamin Peterson wrote: > > A PyPI module is not so great because you'll have to change every > > formatting operation to use a function from a module rather than the % > > operator or the format method. > > I think this is the crux of the issue. Are we trying to say "porting > your existing code will be easier", or "change your existing code to > this new library, and we'll provide the library on 2.x and 3.y" (for > some values of x and y). > > I think the former is the right way to go, but I also think if we do > that we should shoot for 3.4, and this would necessitate a delay in 3.4. > Providing this feature for 3.5 might be too late for the target audience > of code porters. I'm saying hacking in a complex change in a few weeks when there isn't consensus even on the basics of the design just because a few moderately high profile developers failed to understand what "5 years to be the default choice for new projects" meant would be the height of irresponsibility. Create the module, figure out the exact formatting mini-language and semantics, post it on PyPI where compatibility modules like six and future can get at it, and *then* propose syntactic/builtin support for 3.5. The 5 year goal was for the Python 3 ecosystem to be a sufficiently functionally complete alternative to Python 2 for it to be recommended by default for every use case where Python 2 wasn't already being used. Addressing the key remaining barriers to migration for existing Python 2 users would be an excellent objective to attain before we end upstream support for Python 2.7, but it's one that would be better addressed by a slightly shorter dev cycle than normal for 3.5 than it would be by falling into the "just one more feature" trap for Python 3.4. Cheers, Nick. > > Eric. > > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] clinic churn after beta2
On Tue, Jan 7, 2014, at 06:06 PM, Nick Coghlan wrote: > On 8 Jan 2014 08:44, "Eric V. Smith" wrote: > > > > On 1/7/2014 7:33 PM, Benjamin Peterson wrote: > > > A PyPI module is not so great because you'll have to change every > > > formatting operation to use a function from a module rather than the % > > > operator or the format method. > > > > I think this is the crux of the issue. Are we trying to say "porting > > your existing code will be easier", or "change your existing code to > > this new library, and we'll provide the library on 2.x and 3.y" (for > > some values of x and y). > > > > I think the former is the right way to go, but I also think if we do > > that we should shoot for 3.4, and this would necessitate a delay in 3.4. > > Providing this feature for 3.5 might be too late for the target audience > > of code porters. > > I'm saying hacking in a complex change in a few weeks when there isn't > consensus even on the basics of the design just because a few moderately > high profile developers failed to understand what "5 years to be the > default choice for new projects" meant would be the height of > irresponsibility. It's not design from scratch, since it should be fairly close to the 2.x string formatting mini-languages. > > The 5 year goal was for the Python 3 ecosystem to be a sufficiently > functionally complete alternative to Python 2 for it to be recommended by > default for every use case where Python 2 wasn't already being used. > > Addressing the key remaining barriers to migration for existing Python 2 > users would be an excellent objective to attain before we end upstream > support for Python 2.7, but it's one that would be better addressed by a > slightly shorter dev cycle than normal for 3.5 than it would be by > falling > into the "just one more feature" trap for Python 3.4. I think a shorter cycle for 3.5 is fine, too. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] clinic churn after beta2
On 01/07/2014 06:06 PM, Nick Coghlan wrote: Addressing the key remaining barriers to migration for existing Python 2 users would be an excellent objective to attain before we end upstream support for Python 2.7, but it's one that would be better addressed by a slightly shorter dev cycle than normal for 3.5 than it would be by falling into the "just one more feature" trap for Python 3.4. I was thinking about that myself. If we said in advance what features we were shooting for, and it wasn't overly ambitious, we could do a release in six months. No problem. Do we know of any (other) big projects waiting to happen for 3.5? And has a consensus about byte formatting really coalesced that quickly? //arry/ ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] clinic churn after beta2
On 1/7/2014 9:35 PM, Larry Hastings wrote: On 01/07/2014 06:06 PM, Nick Coghlan wrote: Addressing the key remaining barriers to migration for existing Python 2 users would be an excellent objective to attain before we end upstream support for Python 2.7, but it's one that would be better addressed by a slightly shorter dev cycle than normal for 3.5 than it would be by falling into the "just one more feature" trap for Python 3.4. I was thinking about that myself. If we said in advance what features we were shooting for, and it wasn't overly ambitious, we could do a release in six months. No problem. Do we know of any (other) big projects waiting to happen for 3.5? Integration of regex module? And has a consensus about byte formatting really coalesced that quickly? I don't think so. Guido suggested a minimal method and I coded a Python version of a version of that. But many would like *their* favorite feature added. I would like to see a new method tested by, say, mercurial. I also think there are separate questions as to what we want in 3.x for writing 3.x code and what in needed for writing polyglot 2 and 3 code. If the requirements are not the same, I think multi-version modules on Pypi (existing and planned) may in some cases be the better way to go. Terry ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] clinic churn after beta2
On 8 Jan 2014 10:36, "Larry Hastings" wrote: > > On 01/07/2014 06:06 PM, Nick Coghlan wrote: >> >> Addressing the key remaining barriers to migration for existing Python 2 users would be an excellent objective to attain before we end upstream support for Python 2.7, but it's one that would be better addressed by a slightly shorter dev cycle than normal for 3.5 than it would be by falling into the "just one more feature" trap for Python 3.4. > > > I was thinking about that myself. If we said in advance what features we were shooting for, and it wasn't overly ambitious, we could do a release in six months. No problem. > > Do we know of any (other) big projects waiting to happen for 3.5? Extending the PEP 451 import model to allow true reloading of extension modules and the PEP 422 replacement for dynamic metaclass definitions. Also some tweaks to standard stream configuration, support for changing the encoding of a stream and a public API for codecs to declare "I am not a text encoding". I suspect a 6 month cycle would confuse users and inconvenience redistributors, but a 12—17 month cycle so 3.5 is published before 2.7 enters security fix only mode would make a *lot* of sense. Cheers, Nick. > > And has a consensus about byte formatting really coalesced that quickly? > > > /arry > > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
