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
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 e...@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
On 8 Jan 2014 17:06, Georg Brandl g.bra...@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 e...@trueblade.com wrote:
On 1/7/2014 7:33 PM, Benjamin Peterson wrote:
A PyPI module
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
On Wed, Jan 8, 2014 at 2:16 AM, Antoine Pitrou solip...@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
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
Am 08.01.2014 11:08, schrieb Nick Coghlan:
On 8 Jan 2014 17:06, Georg Brandl g.bra...@gmx.net
mailto:g.bra...@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 e...@trueblade.com
On 9 Jan 2014 02:34, Georg Brandl g.bra...@gmx.net wrote:
Am 08.01.2014 11:08, schrieb Nick Coghlan:
On 8 Jan 2014 17:06, Georg Brandl g.bra...@gmx.net mailto:
g.bra...@gmx.net
wrote:
Am 08.01.2014 03:23, schrieb Benjamin Peterson:
On Tue, Jan 7, 2014, at 06:06 PM, Nick Coghlan
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
2014/1/7 Eli Bendersky eli...@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
On Tue, Jan 7, 2014 at 1:26 PM, Victor Stinner victor.stin...@gmail.comwrote:
2014/1/7 Eli Bendersky eli...@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
On Tue, Jan 7, 2014 at 1:18 PM, Eli Bendersky eli...@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
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).
On Jan 7, 2014, at 1:33 PM, Antoine Pitrou solip...@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
On Tue, Jan 7, 2014 at 4:31 PM, Gregory P. Smith g...@krypto.org wrote:
On Tue, Jan 7, 2014 at 1:18 PM, Eli Bendersky eli...@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
вівторок, 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
On Tue, Jan 7, 2014 at 1:33 PM, Antoine Pitrou solip...@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
On 8 Jan 2014 07:11, A.M. Kuchling a...@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
On Tue, Jan 7, 2014 at 4:58 PM, Larry Hastings la...@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
On 8 Jan 2014 08:44, Eric V. Smith e...@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
On Tue, Jan 7, 2014, at 06:06 PM, Nick Coghlan wrote:
On 8 Jan 2014 08:44, Eric V. Smith e...@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
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
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
On 8 Jan 2014 10:36, Larry Hastings la...@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
24 matches
Mail list logo
