22.08.13 02:59, victor.stinner написав(ла):
http://hg.python.org/cpython/rev/0a1e1b929665
changeset: 85308:0a1e1b929665
user:Victor Stinner victor.stin...@gmail.com
date:Thu Aug 22 01:58:12 2013 +0200
summary:
Cleanup test_builtin
files:
Lib/test/test_builtin.py | 16
Terry Reedy wrote:
On 8/15/2013 8:29 AM, R. David Murray wrote:
A number of us (I don't know how many) have clearly been thinking about
Python 4 as the time when we remove cruft. This will not cause any
backward compatibility issues for anyone who has paid heed to the
deprecation warnings,
You forgot self.addCleanup(unlink, TESTFN) (here and in other places).
These functions call write_testfile() which creates the file but also
schedules its removal when the test is done (since my changeset):
def write_testfile(self):
# NB the first 4 lines are also used to test
Le Thu, 22 Aug 2013 14:00:06 +0300,
Petri Lehtinen pe...@digip.org a écrit :
Terry Reedy wrote:
On 8/15/2013 8:29 AM, R. David Murray wrote:
A number of us (I don't know how many) have clearly been thinking
about Python 4 as the time when we remove cruft. This will not
cause any
22.08.13 14:48, Victor Stinner написав(ла):
You forgot self.addCleanup(unlink, TESTFN) (here and in other places).
These functions call write_testfile() which creates the file but also
schedules its removal when the test is done (since my changeset):
def write_testfile(self):
#
On Thu, 22 Aug 2013 16:45:29 +0300, Michael Foord fuzzy...@voidspace.org.uk
wrote:
On 22 Aug 2013, at 14:00, Petri Lehtinen pe...@digip.org wrote:
Terry Reedy wrote:
On 8/15/2013 8:29 AM, R. David Murray wrote:
A number of us (I don't know how many) have clearly been thinking about
On Thu, Aug 22, 2013 at 11:45 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
On 22 Aug 2013, at 14:00, Petri Lehtinen pe...@digip.org wrote:
Django's deprecation policy works like this: They deprecate something
in version A.B. It still works normally in A.B+1, generates a
(silenced)
Hi,
On Thu, Aug 22, 2013 at 1:00 PM, Petri Lehtinen pe...@digip.org wrote:
Removing some cruft on each release can be very painful for users.
Django's deprecation policy works like this: They deprecate something
in version A.B. It still works normally in A.B+1, generates a
(silenced)
On Thu, Aug 22, 2013 at 4:43 PM, R. David Murray rdmur...@bitdance.com wrote:
On Thu, 22 Aug 2013 16:45:29 +0300, Michael Foord fuzzy...@voidspace.org.uk
wrote:
On 22 Aug 2013, at 14:00, Petri Lehtinen pe...@digip.org wrote:
Django's deprecation policy works like this: They deprecate
On Thu, Aug 22, 2013 at 7:45 PM, Donald Stufft don...@stufft.io wrote:
On Aug 22, 2013, at 1:34 PM, Ezio Melotti ezio.melo...@gmail.com wrote:
Hi,
On Thu, Aug 22, 2013 at 1:00 PM, Petri Lehtinen pe...@digip.org wrote:
Removing some cruft on each release can be very painful for users.
On Thu, 22 Aug 2013 20:00:14 +0200, Ezio Melotti ezio.melo...@gmail.com wrote:
On Thu, Aug 22, 2013 at 4:43 PM, R. David Murray rdmur...@bitdance.com
wrote:
On Thu, 22 Aug 2013 16:45:29 +0300, Michael Foord
fuzzy...@voidspace.org.uk wrote:
On 22 Aug 2013, at 14:00, Petri Lehtinen
Hi,
I know that I wrote it more than once, but I consider that my PEP 446
is now ready for a final review:
http://www.python.org/dev/peps/pep-0446/
The implementation is also working, complete and ready for a review.
http://hg.python.org/features/pep-446
http://bugs.python.org/issue18571
I
R. David Murray writes:
It is the *change itself* that causes
action to be needed. If a project has a policy of dealing with deprecated
features when the warnings happen, then they need to do that work before
the version where the feature is removed is released. If they have
a policy
R. David Murray wrote:
So you're still using features deprecated three releases ago, you haven't
checked for DeprecationWarnings and it's Django making your life difficult?
Why not check for the deprecation warnings?
Doing so makes very little difference.
This is my opinion (others
14 matches
Mail list logo
