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
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~
2014/1/7 Eli Bendersky <eliben@gmail.com>:
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
On Tue, Jan 7, 2014 at 1:26 PM, Victor Stinner <victor.stinner@gmail.com>wrote:
2014/1/7 Eli Bendersky <eliben@gmail.com>:
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
On Tue, Jan 7, 2014 at 1:18 PM, Eli Bendersky <eliben@gmail.com> 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
On Tue, Jan 7, 2014 at 4:31 PM, Gregory P. Smith <greg@krypto.org> wrote:
On Tue, Jan 7, 2014 at 1:18 PM, Eli Bendersky <eliben@gmail.com> 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 python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
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.
On Jan 7, 2014, at 1:33 PM, Antoine Pitrou <solipsis@pitrou.net> 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
вівторок, 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?
On Tue, Jan 7, 2014 at 1:33 PM, Antoine Pitrou <solipsis@pitrou.net> 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
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
On 8 Jan 2014 07:11, "A.M. Kuchling" <amk@amk.ca> 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 python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
On Tue, Jan 7, 2014, at 04:29 PM, Nick Coghlan wrote:
On 8 Jan 2014 07:11, "A.M. Kuchling" <amk@amk.ca> 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.
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.
On 8 Jan 2014 08:44, "Eric V. Smith" <eric@trueblade.com> 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 python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
On Tue, Jan 7, 2014, at 06:06 PM, Nick Coghlan wrote:
On 8 Jan 2014 08:44, "Eric V. Smith" <eric@trueblade.com> 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.
Am 08.01.2014 03:23, schrieb Benjamin Peterson:
On Tue, Jan 7, 2014, at 06:06 PM, Nick Coghlan wrote:
On 8 Jan 2014 08:44, "Eric V. Smith" <eric@trueblade.com> 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.
Yes, I think the feature set should be settled upon quickly.
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.
Great! I agree with Nick that 6 months is too short, but I would definitely start with betas after 6 months.
Georg
On 8 Jan 2014 17:06, "Georg Brandl" <g.brandl@gmx.net> wrote:
Am 08.01.2014 03:23, schrieb Benjamin Peterson:
On Tue, Jan 7, 2014, at 06:06 PM, Nick Coghlan wrote:
On 8 Jan 2014 08:44, "Eric V. Smith" <eric@trueblade.com> 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.
Yes, I think the feature set should be settled upon quickly.
I'm not yet convinced restoring more string-like behaviour to bytes is a better solution than a dedicated type specifically for working with ASCII compatible wire protocols (that approach is still being kicked around as a possibility in the parallel discussion on python-ideas).
One key advantage of such a type is that it could be designed to make "text or ASCII bytes" code like the URL parsing as straightforward to write as it was in Python 2, whereas adding formatting to bytes objects wouldn't help with that discrepancy at all.
Cheers, Nick.
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.
Great! I agree with Nick that 6 months is too short, but I would definitely start with betas after 6 months.
Georg
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
Am 08.01.2014 11:08, schrieb Nick Coghlan:
On 8 Jan 2014 17:06, "Georg Brandl" <g.brandl@gmx.net <mailto:g.brandl@gmx.net>> wrote:
Am 08.01.2014 03:23, schrieb Benjamin Peterson:
On Tue, Jan 7, 2014, at 06:06 PM, Nick Coghlan wrote:
On 8 Jan 2014 08:44, "Eric V. Smith" <eric@trueblade.com
<mailto:eric@trueblade.com>> 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.
Yes, I think the feature set should be settled upon quickly.
I'm not yet convinced restoring more string-like behaviour to bytes is a better solution than a dedicated type specifically for working with ASCII compatible wire protocols (that approach is still being kicked around as a possibility in the parallel discussion on python-ideas).
Not sure how that is different from converting everything to str and then converting back after manipulation -- what people want is seamless and efficient working with the "native" type for sockets, files etc.
But I haven't read up these threads, and I hope a PEP will come out of that as well.
One key advantage of such a type is that it could be designed to make "text or ASCII bytes" code like the URL parsing as straightforward to write as it was in Python 2, whereas adding formatting to bytes objects wouldn't help with that discrepancy at all.
Well, even if it works I just hope that wouldn't lead to everyone just using the new type and leaving bytes to rot.
Georg
On 9 Jan 2014 02:34, "Georg Brandl" <g.brandl@gmx.net> wrote:
Am 08.01.2014 11:08, schrieb Nick Coghlan:
On 8 Jan 2014 17:06, "Georg Brandl" <g.brandl@gmx.net <mailto:
wrote:
Am 08.01.2014 03:23, schrieb Benjamin Peterson:
On Tue, Jan 7, 2014, at 06:06 PM, Nick Coghlan wrote:
On 8 Jan 2014 08:44, "Eric V. Smith" <eric@trueblade.com
<mailto:eric@trueblade.com>> 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
> 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.
Yes, I think the feature set should be settled upon quickly.
I'm not yet convinced restoring more string-like behaviour to bytes is a better solution than a dedicated type specifically for working with ASCII compatible wire protocols (that approach is still being kicked around as a
g.brandl@gmx.net>> than the % possibility in
the parallel discussion on python-ideas).
Not sure how that is different from converting everything to str and then converting back after manipulation -- what people want is seamless and efficient working with the "native" type for sockets, files etc.
And that's what I'm saying we *can't* do, because it would put us back in the position of favouring ASCII compatible binary protocol development over normal application code. Is network protocol handling an important use case? Absolutely. However, the core data model needs to continue to push people strongly towards converting binary data to text or another more structured format rather than manipulating the raw bytes directly.
I think PEP 460 is a potentially reasonable idea as a way of helping a couple of specific projects port over, but I also think it's a change that doesn't actually make it substantially easier to write binary protocol handling code in Python 3 in general (the impact on urllib.parse is exactly zero, for example).
There has been a near complete and total lack of experimentation with ways of making binary protocol development in Python 3 fun and straightforward, and, as near as I can tell, this has been due to people insisting on only using the core types, even though we've been suggesting for years that a new, more specialised type may be needed (perhaps based on memoryview, or at least the PEP 3118 buffer API).
I can't blame the people doing the conversions for that - not only am I one of them, but conversions to date have mostly been done based on necessity (stdlib) or due to user demand (third party libraries and frameworks) rather than the "just for fun" style of development that leads people to build the infrastructure they need rather than waiting for someone else to do it for them.
But I haven't read up these threads, and I hope a PEP will come out of that as well.
At this point we need experimental code on PyPI that aims to prove that Py3 can be just as fun for binary protocol manipulation *today* far more than we need proposals to change Python 3.5.
One key advantage of such a type is that it could be designed to make "text or ASCII bytes" code like the URL parsing as straightforward to write as it was in Python 2, whereas adding formatting to bytes objects wouldn't help with that discrepancy at all.
Well, even if it works I just hope that wouldn't lead to everyone just using the new type and leaving bytes to rot.
No, because any new type should *only* be used for ASCII compatible binary protocols. That's an important use case (especially for web protocols), but still just a subset of the overall space of binary formats.
The folks like Armin Ronacher that are currently complaining are the ones that really liked having such a type as a builtin and aren't interested in understanding why we decided it was a seriously problematic default choice. Since they don't have a vested interest in Python 3 (Python 2 works perfectly well for binary protocol handling on POSIX systems, and even Windows for many web use cases, especially for devs that have long ago mastered the rough edges of the Python 2 model), it's natural that their reaction is "I will just use Python 2" and "the core developers don't understand Unicode".
That doesn't make them right, but it *does* mean taking the time to make sure we fully understand the aspects that are causing pain and explore genuine alternatives for addressing them, rather than blindly adding back deeply, deeply error prone constructs that are a frequent source of data corruption when provided as builtins rather than as advanced tools you only reach for when you know you need them.
Cheers, Nick.
Georg
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
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/
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
On 8 Jan 2014 10:36, "Larry Hastings" <larry@hastings.org> 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 python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
On Jan 08, 2014, at 05:39 PM, Nick Coghlan wrote:
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.
18 months is already the typical development cycle for new versions of Python, so it would have to be markedly shorter than that. 6-9 months seems about right, and if we adopted that *and* tightly focused new features in 3.5 to those that making porting from Python 2 easier, then I could see that as a reasonable alternative, especially given the realities of the baked-in time constraints for 3.4.
Adding another beta for clinic churn seems entirely reasonable.
So, let's put "Goals for 3.5" on the agenda for the Language Summit.
-Barry
On mer., 2014-01-08 at 12:06 +1000, Nick Coghlan wrote:
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.
Agreed with Nick here. Let's just add a third beta for the clinic churn.
Regards
Antoine.
On Wed, Jan 8, 2014 at 2:16 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On mer., 2014-01-08 at 12:06 +1000, Nick Coghlan wrote:
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.
Agreed with Nick here. Let's just add a third beta for the clinic churn.
+1
Eli
On 01/08/2014 02:16 AM, Antoine Pitrou wrote:
Agreed with Nick here. Let's just add a third beta for the clinic churn.
Just to be clear: I plan to add a third beta, and have a proposed schedule. I haven't posted it yet because I'm waiting to hear back from the rest of the crew that the schedule will work for them.
Anyway, RC 1 definitely won't be cut on the 18th or released on the 19th.
I'll post here when the slipped schedule is finalized,
//arry/
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/
On Tue, Jan 7, 2014 at 4:58 PM, Larry Hastings <larry@hastings.org> 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
participants (16)
-
A.M. Kuchling -
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Brett Cannon -
Eli Bendersky -
Eric V. Smith -
Ethan Furman -
Georg Brandl -
Gregory P. Smith -
Larry Hastings -
Nick Coghlan -
Serhiy Storchaka -
Terry Reedy -
Victor Stinner -
Łukasz Langa