On Sat, 25 Feb 2012 18:21:40 +0100
Georg Brandl wrote:
>
> Yes, but anybody developing for 3.3.1 will have to specify "3.3.1+".
> Which is kind of defeating the point of giving them micro versions
> at all.
>
> Frankly, the longer we are discussing about this, the more I get the
> impression tha
On 2/25/2012 11:50 AM, Antoine Pitrou wrote:
>> The problem is that you can't say "my code works on Python 3.3". You now
>> have to specify the micro version number as well: "my code works on
>> Python 3.3.1+". We've made this mistake before; I can't see it happening
>> again.
>
> I don't see how
On 02/25/2012 05:55 PM, Antoine Pitrou wrote:
> On Fri, 24 Feb 2012 19:23:36 +0100
> Georg Brandl wrote:
>>
>> > I also think the branches and releases management should be even
>> > simpler:
>> >
>> > - 2.7: as today
>> > - 3.3: bug fixes + stdlib enhancements
>> > - default: language enhanceme
On Fri, 24 Feb 2012 19:23:36 +0100
Georg Brandl wrote:
>
> > I also think the branches and releases management should be even
> > simpler:
> >
> > - 2.7: as today
> > - 3.3: bug fixes + stdlib enhancements
> > - default: language enhancements / ABI-breaking changes
> >
> > Every 6 months, a new
On Sat, 25 Feb 2012 11:24:47 -0500
"Eric V. Smith" wrote:
> On 2/25/2012 11:18 AM, Zachary Ware wrote:
> > Anyhow; I have to say I like Nick's idea put forth in PEP 413, but I
> > agree that the extra versioning info could get pretty awkward.
> > Therefore, why not just make stdlib upgrades part o
On 2/25/2012 11:18 AM, Zachary Ware wrote:
> Anyhow; I have to say I like Nick's idea put forth in PEP 413, but I
> agree that the extra versioning info could get pretty awkward.
> Therefore, why not just make stdlib upgrades part of the regular
> maintenance releases? As long as there is absolutel
Quick disclaimer: this is the first time I've replied on any Python list,
and thus am not entirely sure what I'm doing. Hopefully this message goes
as expected :)
Anyhow; I have to say I like Nick's idea put forth in PEP 413, but I agree
that the extra versioning info could get pretty awkward. The
On Sat, Feb 25, 2012 at 4:59 AM, Brett Cannon wrote:
> On Fri, Feb 24, 2012 at 13:23, Georg Brandl wrote:
>> Am 24.02.2012 18:46, schrieb Antoine Pitrou:
>> > Overall, I like the principle of this PEP, but I really dislike the
>> > dual version numbering it introduces. Such a numbering scheme wil
On Sat, Feb 25, 2012 at 05:32, Matt Joiner wrote:
> There are so many third party modules languishing because inferior forms
> exist in the stdlib, and no centralized method for their recommendation and
> discovery.
That's interesting. Do you have a list of these? Maybe a blog post somewhere?
___
On Sat, Feb 25, 2012 at 1:32 PM, Matt Joiner wrote:
> Evidently some modules have to ship with core if they are required (sys),or
> expose internals (os, gc). Others are clearly extras, (async{ore,hat},
> subprocess, unittest, select).
There's a whole raft of additional dependencies introduced by
Why not cut the (external) stdlib before each minor release?
Testing new language features is not the role of a public release, this is
no reason to require ownership on a module.
Evidently some modules have to ship with core if they are required (sys),or
expose internals (os, gc). Others are cle
On Fri, Feb 24, 2012 at 21:08, Matt Joiner wrote:
> I think every minor release should be fully supported. The current rate of
> change is very high and there's a huge burden on implementers and
> production users to keep up, so much so that upgrading is undesirable
> except for serious enthusias
I think every minor release should be fully supported. The current rate of
change is very high and there's a huge burden on implementers and
production users to keep up, so much so that upgrading is undesirable
except for serious enthusiasts.
Include just the basics and CPython specific modules in
On Fri, Feb 24, 2012 at 13:23, Georg Brandl wrote:
> Am 24.02.2012 18:46, schrieb Antoine Pitrou:
> >
> > Hello,
> >
> > On Sat, 25 Feb 2012 03:24:27 +1000
> > Nick Coghlan wrote:
> >> To allow the PEP 407 authors to focus on making the case for doing
> >> full CPython releases every 6 months (i
Am 24.02.2012 18:46, schrieb Antoine Pitrou:
>
> Hello,
>
> On Sat, 25 Feb 2012 03:24:27 +1000
> Nick Coghlan wrote:
>> To allow the PEP 407 authors to focus on making the case for doing
>> full CPython releases every 6 months (including language spec
>> updates), I've created PEP 413 as a compe
Hello,
On Sat, 25 Feb 2012 03:24:27 +1000
Nick Coghlan wrote:
> To allow the PEP 407 authors to focus on making the case for doing
> full CPython releases every 6 months (including language spec
> updates), I've created PEP 413 as a competing proposal.
>
> It leaves the current language version
To allow the PEP 407 authors to focus on making the case for doing
full CPython releases every 6 months (including language spec
updates), I've created PEP 413 as a competing proposal.
It leaves the current language versioning (and rate of change) alone,
while adding an additional date based stand
17 matches
Mail list logo
