On Jan 19, 2012 9:28 AM, "Bill Janssen" wrote:
> I'm not sure how much of a problem this really is. I continually build
> fairly complicated systems with Python that do a lot of HTTP networking,
> for instance. It's fairly easy to replace use of the standard library
> modules with use of Tornado
Nick Coghlan wrote:
> On Thu, Jan 19, 2012 at 10:19 AM, Steven D'Aprano wrote:
> > Brett Cannon wrote:
> > Do we have any evidence of this alleged bitrot? I spend a lot of time on the
> > comp.lang.python newsgroup and I see no evidence that people using Python
> > believe the standard library i
On Jan 19, 2012, at 12:17 PM, Antoine Pitrou wrote:
>The main problem I see with this is that Python 3 was a big
>disruptive event for the community, and calling a new version "Python
>4" may make people anxious at the prospect of compatibility breakage.
s/was/is/
The Python 3 transition is ongo
On Thu, Jan 19, 2012 at 9:17 PM, Antoine Pitrou wrote:
> If I were a casual user of a piece of software, I'd really find such a
> numbering scheme complicated and intimidating. I don't think most users
> want such a level of information.
I think the ideal numbering scheme from a *new* user point
On Thu, 19 Jan 2012 11:03:15 +1000
Nick Coghlan wrote:
>
> 1. I believe the PEP currently proposes just taking the "no more than
> 9" limit off the minor version of the language. Feature releases would
> just come out every 6 months, with every 4th release flagged as a
> language release.
With t
On 1/18/2012 8:06 PM, Nick Coghlan wrote:
On Thu, Jan 19, 2012 at 10:19 AM, Steven D'Aprano wrote:
Do we have any evidence of this alleged bitrot? I spend a lot of time on the
comp.lang.python newsgroup and I see no evidence that people using Python
believe the standard library is rotting from
On Thu, Jan 19, 2012 at 10:19 AM, Steven D'Aprano wrote:
> Brett Cannon wrote:
> Do we have any evidence of this alleged bitrot? I spend a lot of time on the
> comp.lang.python newsgroup and I see no evidence that people using Python
> believe the standard library is rotting from lack of attention
On Thu, Jan 19, 2012 at 7:31 AM, fwierzbi...@gmail.com
wrote:
> On Wed, Jan 18, 2012 at 9:56 AM, Brett Cannon wrote:
>
>> Doing a release every 6 months that includes updates to the stdlib and
>> bugfixes to the language/VM also benefits other VMs by getting compatibility
>> fixes in faster. All
Brett Cannon wrote:
And honestly, if we don't go with this I'm with Georg's comment in another
email of beginning to consider stripping the stdlib down to core libraries
to help stop with the bitrot (sorry, Paul). If we can't attract new
replacements for modules we can't ditch because of backwar
On Wed, Jan 18, 2012 at 9:56 AM, Brett Cannon wrote:
> Doing a release every 6 months that includes updates to the stdlib and
> bugfixes to the language/VM also benefits other VMs by getting compatibility
> fixes in faster. All of the other VM maintainers have told me that keeping
> the stdlib no
Am 18.01.2012 18:56, schrieb Brett Cannon:
> IOW we would have a language moratorium every 2 years (i.e. between LTS
> releases) while switching to a 6 month release cycle for language/VM bugfixes
> and full stdlib releases?
That is certainly a possibility (it's listed as an open issue in the PEP
On Wed, Jan 18, 2012 at 09:08, Nick Coghlan wrote:
> On Wed, Jan 18, 2012 at 10:30 PM, Antoine Pitrou
> wrote:
> > Splitting the stdlib:
> > - requires someone to do the splitting (highly non-trivial given the
> > interactions of some modules with interpreter details or low-level C
> > code)
> >
Nick Coghlan writes:
> >From the stdlib feature development branch (these are the new interim
> releases with standard library updates only as proposed by PEP 407):
> Python 3.3.1 + stdlib 13.02.0 (~February 2013)
> Python 3.3.2 + stdlib 13.08.0 (~August 2013)
> Python 3.3.3 + stdlib 14.02.
On Wed, Jan 18, 2012 at 10:30 PM, Antoine Pitrou wrote:
> Splitting the stdlib:
> - requires someone to do the splitting (highly non-trivial given the
> interactions of some modules with interpreter details or low-level C
> code)
> - requires setting up separate resources (continuous integration w
Le mercredi 18 janvier 2012 à 21:26 +1000, Nick Coghlan a écrit :
> I'm also wholly in agreement with Ezio that using the
> same versioning scheme for both full releases and interim releases is
> thoroughly confusing for users
It's a straight-forward way to track the feature support of a release
15 matches
Mail list logo
