Raymond Hettinger rcn.com> writes:
>
> >>> You might also want to collect a list of serious changes that you
> >>> want in this release;
>
> I'm making minor updates to the decimal module to match the 1.68 version of
the spec.
What about decimal-in-C, by the way? Is anyone still working on it?
I'm making minor updates to the decimal module to match the 1.68 version of the
spec.
Looks like most was already done. Just needs some doc fixes.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
You might also want to collect a list of serious changes that you
want in this release;
I'm making minor updates to the decimal module to match the 1.68 version of the
spec.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
2009/3/9 :
>
> >>> You might also want to collect a list of serious changes that you
> >>> want in this release;
>
> http://bugs.python.org/issue4847
>
> Not yet fixed. Needs:
>
> * Decision about the correct fix (I think it will involve an API
> change).
>
> * Test case and a pa
2009/3/9 Raymond Hettinger :
>> >>> You might also want to collect a list of serious changes that you
>> >>> want in this release;
>
> Bob Ippolito has a good sized patch to update the json module
> and improve its performance.
>
> http://bugs.python.org/issue4136
...and it's already on the PE
>>> You might also want to collect a list of serious changes that you
>>> want in this release;
Bob Ippolito has a good sized patch to update the json module
and improve its performance.
http://bugs.python.org/issue4136
Raymond
___
Python-Dev
>>> You might also want to collect a list of serious changes that you
>>> want in this release;
http://bugs.python.org/issue4847
Not yet fixed. Needs:
* Decision about the correct fix (I think it will involve an API
change).
* Test case and a patch.
* Probably small
2009/3/9 Terry Reedy :
> Benjamin Peterson wrote:
>>
>>> You might also want to collect a list of serious changes that you want
>>> in this release; I know I/O in C is on the list (and without it I
>>> wouldn't consider it worth releasing) but there may be others. The
>>> developers of such feature
Benjamin Peterson wrote:
You might also want to collect a list of serious changes that you want
in this release; I know I/O in C is on the list (and without it I
wouldn't consider it worth releasing) but there may be others. The
developers of such features ought to be on board with delivering t
Stephen J. Turnbull wrote:
> A suggestion, though. View the contribution visualization video based
> on the commit log (the URL was posted here a while back, but I don't
> seem to have it offhand), which shows what a vibrant community this is
> in a very graphic way.
There's one here:
http://www.
> I guess I'm saying that I'm surprised people aren't a bit more
> appreciative of the opportunity to review code.
Not sure what "people" you are referring to here which aren't
appreciative of the opportunity to review code. Committers?
Non-committers?
> I don't think I would even be on this lis
> I hope that somebody will pick up the slack here, because review is
> really important to the workflow, and getting more people involved in
> reviewing at some level is more important (because it's less
> glamorous in itself) than attracting coders.
Ok, then let me phrase it this way: if somebod
Tennessee Leeuwenburg writes:
> > I hope that somebody will pick up the slack here, because review is
> > really important to the workflow, and getting more people involved in
> > reviewing at some level is more important (because it's less
> > glamorous in itself) than attracting coders.
>
> Well, that happens. An alternative to withdrawing entirely, would be
> increasing the price (eg, to ten patches as you originally suggested).
> Or specifying windows in your calendar when the offer is open. Eg,
> avoid doubling up on release times when you need make time to build
> installers e
"Martin v. Löwis" writes:
> >From time to time, people ask what they can do push a change into Python
> that they really think is important. I once offered that people who
> want a patch in Python really badly should review 10 other patches in
> return, up to the point where they make a recomm
> So what is the solution?
In the specific case, I don't know. I recall that somebody offered to
pick up the change. I really didn't mean to suggest that the patch
will remain unnoticed - it was just a warning that it *might* remain
unnoticed.
The more general issue is that of patches being unrev
On Thu, Mar 5, 2009 at 10:53 AM, Brad Miller wrote:
>
>
> On Mon, Mar 2, 2009 at 4:22 PM, "Martin v. Löwis"
> wrote:
>>
>> > Would whoever is responsible for IDLE please take a look at the patches
>> > I submitted for Python 2 & 3 [tracker IDs 5233 and 5234 respectively].
>> > These change the be
On Mon, Mar 2, 2009 at 4:22 PM, "Martin v. Löwis" wrote:
> > Would whoever is responsible for IDLE please take a look at the patches
> > I submitted for Python 2 & 3 [tracker IDs 5233 and 5234 respectively].
> > These change the behavior of IDLE so that IDLESTARTUP or PYTHONSTARTUP
> > files are e
2009/3/3 Daniel (ajax) Diniz :
> Benjamin, I'd like to nominate a couple (minor) RFEs[1] and bug
> fixes[2] for 3.1. By 'nominate' I mean 'group related issues together,
> offer tests, docs, patches and/or reviews as needed and
> ask-pretty-please-for-inclusion' :)
>
> Would early post-3.1a1 versus
Mitchell L Model wrote:
> Would whoever is responsible for IDLE please take a look at the patches
> I submitted for Python 2 & 3 [tracker IDs 5233 and 5234 respectively].
[...]
> I would really like to see them in 3.1. The patch is already there;
> someone just has to do whatever gets done with pat
Hi,
Benjamin Peterson wrote:
> 3.1a1 March 7
> 3.1a2 April 4
> 3.1b1 May 2
> 3.1rc1 May 30
> 3.1rc2 June 13
> 3.1 Final June 27
Benjamin, I'd like to nominate a couple (minor) RFEs[1] and bug
fixes[2] for 3.1. By 'nominate' I mean 'group related issues together,
offer tests, docs, patches and/or
> Would whoever is responsible for IDLE please take a look at the patches
> I submitted for Python 2 & 3 [tracker IDs 5233 and 5234 respectively].
> These change the behavior of IDLE so that IDLESTARTUP or PYTHONSTARTUP
> files are executed with each restart. This allows loading frequently
> used p
Would whoever is responsible for IDLE please take a look at the
patches I submitted for Python 2 & 3 [tracker IDs 5233 and 5234
respectively]. These change the behavior of IDLE so that IDLESTARTUP
or PYTHONSTARTUP files are executed with each restart. This allows
loading frequently used package
2009/3/1 Paul Moore :
>
> Is it worth getting simplegeneric exposed in 3.1
> (http://bugs.python.org/issue5135)? If it's going to be in 2.7, I'd
> like to see it hit 3.1. The patch is against trunk (for 2.7) at the
> moment, I'm not sure what the process would be for forward-porting it
> (do I gene
Paul Moore wrote:
> 2009/2/27 Benjamin Peterson :
>> 2009/2/27 Nick Coghlan schrieb:
>>> I should have a PEP (and implementation) ready for alpha 2 to address
>>> the current discrepancy between contextlib.nested and actual nested with
>>> statements:
>>> http://bugs.python.org/issue5251
>>>
>>> I
2009/2/27 Benjamin Peterson :
> 2009/2/27 Nick Coghlan schrieb:
>>
>> I should have a PEP (and implementation) ready for alpha 2 to address
>> the current discrepancy between contextlib.nested and actual nested with
>> statements:
>> http://bugs.python.org/issue5251
>>
>> If you do add a reference
2009/2/27 Nick Coghlan schrieb:
>
> I should have a PEP (and implementation) ready for alpha 2 to address
> the current discrepancy between contextlib.nested and actual nested with
> statements:
> http://bugs.python.org/issue5251
>
> If you do add a reference to that bug report to the release PEP,
Benjamin Peterson wrote:
> 2009/2/27 Raymond Hettinger :
> You might also want to collect a list of serious changes that you want
> in this release; I know I/O in C is on the list (and without it I
> wouldn't consider it worth releasing) but there may be others. The
> developers of
2009/2/27 Raymond Hettinger :
>
>>> > You might also want to collect a list of serious changes that you want
>>> > in this release; I know I/O in C is on the list (and without it I
>>> > wouldn't consider it worth releasing) but there may be others. The
>>> > developers of such features ought to be
> You might also want to collect a list of serious changes that you want
> in this release; I know I/O in C is on the list (and without it I
> wouldn't consider it worth releasing) but there may be others. The
> developers of such features ought to be on board with delivering their
> code before
Benjamin,
> > You might also want to collect a list of serious changes that you want
> > in this release; I know I/O in C is on the list (and without it I
> > wouldn't consider it worth releasing) but there may be others. The
> > developers of such features ought to be on board with delivering the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 17, 2009, at 8:55 AM, Gregor Lingl wrote:
Is the intention to release 2.7 and 3.1 in parallel?
I don't think we should this time. We want to get 3.1 out sooner than
the typical 18 month development cycle, and I think we should
concentr
On Tue, Feb 17, 2009 at 7:55 AM, Gregor Lingl wrote:
>>
>> I've started a list on the release PEP [1].
>>
>> [1] http://www.python.org/dev/peps/pep-0375/
>>
>
> Is the intention to release 2.7 and 3.1 in parallel?
No.
>
> I suspect, comparing this to
>
> http://www.python.org/dev/peps/pep-0373/
Benjamin Peterson schrieb:
On Sun, Feb 15, 2009 at 10:59 AM, Guido van Rossum wrote...
Something like this?
3.1a1 March 7
3.1a2 April 4
3.1b1 May 2
3.1rc1 May 30
3.1rc2 June 13
3.1 Final June 27
That sounds reasonable. I will try to enforce a fairly strict
stability policy during t
On Sun, Feb 15, 2009 at 10:59 AM, Guido van Rossum wrote:
> On Sat, Feb 14, 2009 at 12:29 PM, Benjamin Peterson
> wrote:
>> 3.1a1 March 7 (Saturday)
>> 3.1a2 April 11 (Saturday)
>> 3.1b1 May 2 (Saturday)
>> 3.1b2 May 23 (Saturday)
>> 3.1rc1 June 13 (Saturday)
>> 3.1rc2 June 27 (Saturday)
>
> And
On Sat, Feb 14, 2009 at 12:29 PM, Benjamin Peterson wrote:
> Here's a very tentative 3.1 release schedule.
Thanks! Glad you're taking your new role of release manager seriously
and are starting to plan ahead.
> 3.1a1 March 7 (Saturday)
> 3.1a2 April 11 (Saturday)
> 3.1b1 May 2 (Saturday)
> 3.1b2
Here's a very tentative 3.1 release schedule.
3.1a1 March 7 (Saturday)
3.1a2 April 11 (Saturday)
3.1b1 May 2 (Saturday)
3.1b2 May 23 (Saturday)
3.1rc1 June 13 (Saturday)
3.1rc2 June 27 (Saturday)
I'm interested in your feedback with regards to the amount of time in
beta and RC phase. Do you think
37 matches
Mail list logo
