Quoting Benjamin Peterson :
This means we need to talk about how many more 2.7 releases there are
going to be. At the release of 2.7.0, I thought we promised 5 years of
bugfix maintenance, but my memory may be fuddled.
I'd like to promote the idea to abandon 2.7 bug fix releases earlier
than
On Sun, Apr 7, 2013 at 7:02 AM, Benjamin Peterson wrote:
> Per my last message, 2.7.4 has at long last been released. I apologize
> for the long interval between 2.7.3 and 2.7.4. To create more
> determinism in the future, I will be soon updating PEP 373 with
> approximate dates of future 2.7 bugf
On Sat, Apr 6, 2013 at 2:02 PM, Benjamin Peterson wrote:
> juncture 5 total years of maintenance is reasonable. This means there
> will be approximately 4 more 2.7 releases.
That's good. From the subject of the email, I though you were
announcing "This is the end of 2.7.x releases".
2 more year
On 4/6/2013 5:11 PM, Georg Brandl wrote:
Am 06.04.2013 23:02, schrieb Benjamin Peterson:
Per my last message, 2.7.4 has at long last been released. I apologize
for the long interval between 2.7.3 and 2.7.4. To create more
determinism in the future, I will be soon updating PEP 373 with
approximat
On Apr 6, 2013, at 2:02 PM, Benjamin Peterson wrote:
> we need to talk about how many more 2.7 releases there are
> going to be. At the release of 2.7.0, I thought we promised 5 years of
> bugfix maintenance, but my memory may be fuddled.
I don't we need to make any "promises" beyond 5 years,
In article
,
Benjamin Peterson wrote:
> 2013/4/6 Gregory P. Smith :
> What I like about 6 months is that its short enough, so we don't have
> feel bad about not taking a certain change; it can just be pushed to
> the next no-too-far-away release. A year is quite a while to wait for
> a fix to be
2013/4/6 Gregory P. Smith :
> I agree with Benjamin though is it really necessary to do two 2.7 releases a
> year for the last two years? that's rather rapid (but as the release
> manager its your call).
What I like about 6 months is that its short enough, so we don't have
feel bad about not taki
I agree with Benjamin though is it really necessary to do two 2.7 releases
a year for the last two years? that's rather rapid (but as the release
manager its your call).
A few of us (sorry I forgot who all was there though I think Martin was?)
had a discussion at PyCon a few weeks ago and seemed
Am 06.04.2013 23:11, schrieb Georg Brandl:
> Am 06.04.2013 23:02, schrieb Benjamin Peterson:
>> Per my last message, 2.7.4 has at long last been released. I apologize
>> for the long interval between 2.7.3 and 2.7.4. To create more
>> determinism in the future, I will be soon updating PEP 373 with
On Sat, 6 Apr 2013 17:02:17 -0400
Benjamin Peterson wrote:
> Obviously, there will be people who would be
> happy if we kept maintaining 2.7 until 2025, but I think at this
> juncture 5 total years of maintenance is reasonable. This means there
> will be approximately 4 more 2.7 releases.
>
> Tho
Am 06.04.2013 23:02, schrieb Benjamin Peterson:
> Per my last message, 2.7.4 has at long last been released. I apologize
> for the long interval between 2.7.3 and 2.7.4. To create more
> determinism in the future, I will be soon updating PEP 373 with
> approximate dates of future 2.7 bugfix release
Per my last message, 2.7.4 has at long last been released. I apologize
for the long interval between 2.7.3 and 2.7.4. To create more
determinism in the future, I will be soon updating PEP 373 with
approximate dates of future 2.7 bugfix releases. I will be aiming for
6 month intervals.
This means w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On behalf of the Python development team, I am pleased to announce the
final releases of Python 3.2.4 and 3.3.1.
Python 3.2.4 is the final regular maintenance release for the Python 3.2
series, while Python 3.3.1 is the first maintenance release for t
On Fri, Apr 5, 2013 at 6:34 PM, Terry Jan Reedy wrote:
> 2. int(rational): for floats, Fractions, and Decimals, this returns the
> integral part, truncating toward 0. Decimal and float have __int__ methods.
> Fractions, to my surprise, does not, so int must use __floor__ or __round__
> as a backu
I'm thrilled to announce the release of Python 2.7.4.
2.7.4 is the latest maintenance release in the Python 2.7 series. It includes
hundreds of bugfixes to the core language and standard library.
Downloads are at
http://python.org/download/releases/2.7.4/
As always, please report bugs to
Having gotten positive input from Todd, I've now done the move.
2013/4/6 Benjamin Peterson :
> I noticed IDLE changes were being put under the "library" section in
> Misc/NEWS. How about creating a IDLE section?
>
> --
> Regards,
> Benjamin
--
Regards,
Benjamin
On 06.04.13 17:58, Benjamin Peterson wrote:
I noticed IDLE changes were being put under the "library" section in
Misc/NEWS. How about creating a IDLE section?
http://bugs.python.org/issue17221
http://bugs.python.org/issue17506
___
Python-Dev mailing
On 4/4/2013 10:04 PM, Steven D'Aprano wrote:
When I call int(), I'm expecting an int.
We agree so far...,
> That includes well-behaved subclasses of int that continue to behave
> like ints in all the ways that matter.
but not here. I currently expect an actual int instance for 3 reasons.
1.
Am 06.04.2013 16:58, schrieb Benjamin Peterson:
> I noticed IDLE changes were being put under the "library" section in
> Misc/NEWS. How about creating a IDLE section?
There is also Lib/idlelib/NEWS.txt. It also contains IDLE news items
and is shown in a dialog box from within IDLE.
IMO it's fine
Done, thanks
On Sat, Apr 6, 2013 at 5:41 PM, Eli Bendersky wrote:
> It currently says:
>
> "Let's also change the rest of the program to make the new functionality
> makes more sense"
>
> This can be changed to:
>
> "Let's also change the rest of the program so that the new functionality
> makes
I noticed IDLE changes were being put under the "library" section in
Misc/NEWS. How about creating a IDLE section?
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
htt
It currently says:
"Let's also change the rest of the program to make the new functionality
makes more sense"
This can be changed to:
"Let's also change the rest of the program so that the new functionality
makes more sense".
Eli
On Sat, Apr 6, 2013 at 7:25 AM, Andrew Svetlov wrote:
> Do yo
Do you mean something like:
«Let's also change the rest of the program to make the new functionality:»
???
On Sat, Apr 6, 2013 at 6:41 AM, Eli Bendersky wrote:
>
> On Fri, Apr 5, 2013 at 1:40 AM, andrew.svetlov
> wrote:
>>
>> http://hg.python.org/cpython/rev/6cf485ffd325
>> changeset: 83110:6c
23 matches
Mail list logo