Re: [Python-Dev] cpython: Cleanup test_builtin
22.08.13 02:59, victor.stinner написав(ла): http://hg.python.org/cpython/rev/0a1e1b929665 changeset: 85308:0a1e1b929665 user:Victor Stinner date:Thu Aug 22 01:58:12 2013 +0200 summary: Cleanup test_builtin files: Lib/test/test_builtin.py | 16 1 files changed, 4 insertions(+), 12 deletions(-) [...] def test_open(self): self.write_testfile() fp = open(TESTFN, 'r') -try: +with fp: self.assertEqual(fp.readline(4), '1+1\n') self.assertEqual(fp.readline(), 'The quick brown fox jumps over the lazy dog.\n') self.assertEqual(fp.readline(4), 'Dear') self.assertEqual(fp.readline(100), ' John\n') self.assertEqual(fp.read(300), 'XXX'*100) self.assertEqual(fp.read(1000), 'YYY'*100) -finally: -fp.close() -unlink(TESTFN) You forgot self.addCleanup(unlink, TESTFN) (here and in other places). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When to remove deprecated stuff
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, but will for those who haven't. The question > >then becomes, is it better to "bundle" these removals into the > >Python 4 release, or do them incrementally? > > 4.0 will be at most 6 releases after the upcoming 3.4, which is 9 to > 12 years, which is 7 to 10 years after any regular 2.7 maintainance > ends. > > The deprecated unittest synonyms are documented as being removed in > 4.0 and that already defines 4.0 as a future cruft-removal release. > However, I would not want it defined as the only cruft-removal > release and used as a reason or excuse to suspend removals until > then. I would personally prefer to do little* removals > incrementally, as was done before the decision to put off 2.x > removals to 3.0. So I would have 4.0 be an 'extra' or 'bigger' cruft > removal release, but not the only one. > > * Removing one or two pure synonyms or little used features from a > module. The unittest synonym removal is not 'little' because there > are 13 synonyms and at least some were well used. > > >If we are going to do them incrementally we should make that decision > >soonish, so that we don't end up having a whole bunch happen at once > >and defeat the (theoretical) purpose of doing them incrementally. > > > >(I say theoretical because what is the purpose? To spread out the > >breakage pain over multiple releases, so that every release breaks > >something?) > > Little removals will usually break something, but not most things. > Yes, I think it better to upset a few people with each release than > lots of people all at once. I think enabling deprecation notices in > unittest is a great idea. Among other reasons, it should spread the > effect of bigger removals scheduled farther in the future over the > extended deprecation period. > > Most deprecation notices should provide an alternative. (There might > be an exception is for things that should not be done ;-). For > module removals, the alternative should be a legacy package on PyPI. 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) DeprecationWarning in A.B+2, and is finally removed in A.B+3. So if I haven't read through the full release notes of each release nor enabled DeprecationWarnings, I end up having something broken each time I upgrade Django. I hope the same will not start happening each time I upgrade Python. When the removals happen on major version boundaries, it should be more evident that something will break. Then people can enable DepreationWarnings and test all the affected code thoroughly with the new version before upgrading. Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Cleanup test_builtin
> 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 input, below fp = open(TESTFN, 'w') self.addCleanup(unlink, TESTFN) ... Victor 2013/8/22 Serhiy Storchaka : > 22.08.13 02:59, victor.stinner написав(ла): > >> http://hg.python.org/cpython/rev/0a1e1b929665 >> changeset: 85308:0a1e1b929665 >> user:Victor Stinner >> date:Thu Aug 22 01:58:12 2013 +0200 >> summary: >>Cleanup test_builtin >> >> files: >>Lib/test/test_builtin.py | 16 >>1 files changed, 4 insertions(+), 12 deletions(-) > > [...] > >> def test_open(self): >> self.write_testfile() >> fp = open(TESTFN, 'r') >> -try: >> +with fp: >> self.assertEqual(fp.readline(4), '1+1\n') >> self.assertEqual(fp.readline(), 'The quick brown fox jumps >> over the lazy dog.\n') >> self.assertEqual(fp.readline(4), 'Dear') >> self.assertEqual(fp.readline(100), ' John\n') >> self.assertEqual(fp.read(300), 'XXX'*100) >> self.assertEqual(fp.read(1000), 'YYY'*100) >> -finally: >> -fp.close() >> -unlink(TESTFN) > > > You forgot self.addCleanup(unlink, TESTFN) (here and in other places). > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When to remove deprecated stuff
Le Thu, 22 Aug 2013 14:00:06 +0300, Petri Lehtinen 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 backward compatibility issues for anyone who has paid > > >heed to the deprecation warnings, but will for those who haven't. > > >The question then becomes, is it better to "bundle" these removals > > >into the Python 4 release, or do them incrementally? > > > > 4.0 will be at most 6 releases after the upcoming 3.4, which is 9 to > > 12 years, which is 7 to 10 years after any regular 2.7 maintainance > > ends. > > > > The deprecated unittest synonyms are documented as being removed in > > 4.0 and that already defines 4.0 as a future cruft-removal release. > > However, I would not want it defined as the only cruft-removal > > release and used as a reason or excuse to suspend removals until > > then. I would personally prefer to do little* removals > > incrementally, as was done before the decision to put off 2.x > > removals to 3.0. So I would have 4.0 be an 'extra' or 'bigger' cruft > > removal release, but not the only one. > > > > * Removing one or two pure synonyms or little used features from a > > module. The unittest synonym removal is not 'little' because there > > are 13 synonyms and at least some were well used. > > > > >If we are going to do them incrementally we should make that > > >decision soonish, so that we don't end up having a whole bunch > > >happen at once and defeat the (theoretical) purpose of doing them > > >incrementally. > > > > > >(I say theoretical because what is the purpose? To spread out the > > >breakage pain over multiple releases, so that every release breaks > > >something?) > > > > Little removals will usually break something, but not most things. > > Yes, I think it better to upset a few people with each release than > > lots of people all at once. I think enabling deprecation notices in > > unittest is a great idea. Among other reasons, it should spread the > > effect of bigger removals scheduled farther in the future over the > > extended deprecation period. > > > > Most deprecation notices should provide an alternative. (There might > > be an exception is for things that should not be done ;-). For > > module removals, the alternative should be a legacy package on PyPI. > > 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) DeprecationWarning in A.B+2, and is finally removed in > A.B+3. So if I haven't read through the full release notes of each > release nor enabled DeprecationWarnings, I end up having something > broken each time I upgrade Django. So, again, perhaps we can stop silencing DeprecationWarning. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Cleanup test_builtin
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): # NB the first 4 lines are also used to test input, below fp = open(TESTFN, 'w') self.addCleanup(unlink, TESTFN) ... Oh, sorry. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When to remove deprecated stuff
On Thu, 22 Aug 2013 16:45:29 +0300, Michael Foord wrote: > > On 22 Aug 2013, at 14:00, Petri Lehtinen 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 > >>> "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, but will for those who haven't. The question > >>> then becomes, is it better to "bundle" these removals into the > >>> Python 4 release, or do them incrementally? > >> > >> 4.0 will be at most 6 releases after the upcoming 3.4, which is 9 to > >> 12 years, which is 7 to 10 years after any regular 2.7 maintainance > >> ends. > >> > >> The deprecated unittest synonyms are documented as being removed in > >> 4.0 and that already defines 4.0 as a future cruft-removal release. > >> However, I would not want it defined as the only cruft-removal > >> release and used as a reason or excuse to suspend removals until > >> then. I would personally prefer to do little* removals > >> incrementally, as was done before the decision to put off 2.x > >> removals to 3.0. So I would have 4.0 be an 'extra' or 'bigger' cruft > >> removal release, but not the only one. > >> > >> * Removing one or two pure synonyms or little used features from a > >> module. The unittest synonym removal is not 'little' because there > >> are 13 synonyms and at least some were well used. > >> > >>> If we are going to do them incrementally we should make that decision > >>> soonish, so that we don't end up having a whole bunch happen at once > >>> and defeat the (theoretical) purpose of doing them incrementally. > >>> > >>> (I say theoretical because what is the purpose? To spread out the > >>> breakage pain over multiple releases, so that every release breaks > >>> something?) > >> > >> Little removals will usually break something, but not most things. > >> Yes, I think it better to upset a few people with each release than > >> lots of people all at once. I think enabling deprecation notices in > >> unittest is a great idea. Among other reasons, it should spread the > >> effect of bigger removals scheduled farther in the future over the > >> extended deprecation period. > >> > >> Most deprecation notices should provide an alternative. (There might > >> be an exception is for things that should not be done ;-). For > >> module removals, the alternative should be a legacy package on PyPI. > > > > 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) DeprecationWarning in A.B+2, and is finally removed in > > A.B+3. So if I haven't read through the full release notes of each > > release nor enabled DeprecationWarnings, I end up having something > > broken each time I upgrade Django. > > > > 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 obviously differ): Putting in one big chunk of effort at a major release boundary is easier to schedule than putting in a chunk of effort on *every* feature release. More importantly, having it happen only at the major release boundary means there's only one hard deadline every ten-ish years, rather than a hard deadline every 1.5 years. Expecting things to break when you switch to the new feature release makes one view feature releases with dread rather than excitement. This applies whether or not one is testing with deprecation warnings on. Yes, there's a little less pressure if you are making the fixes on the deprecation release boundary, because you can always ship the code anyway if it is winds up being too big of a bear, so you have more scheduling flexibility. But you still face the *psychological* hurdle of "feature release upgrade...will need to fix the all the things they've deprecated...let's put that off". Especially since what we are talking about here is the *big* cruft, and thus more likely to be a pain to fix. So, the operant question is which do the majority of *users* prefer, some required "fix my code" work at every feature release, or the ability to schedule the "fix my code" work at their convenience, with a hard deadline (for anything not already fixed) at the major release boundary? Note that under this suggested scenario the amount of work people will need to do for Python4 will be trivial compared to that for Python3, and there won't be any controversy about single-code-base vs conversion, because we'll still be maintaining backward compatibility and just removing cruft. So the user base will probably heave a sigh of relief (those that were a
Re: [Python-Dev] When to remove deprecated stuff
On Thu, Aug 22, 2013 at 11:45 PM, Michael Foord wrote: > On 22 Aug 2013, at 14:00, Petri Lehtinen 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) DeprecationWarning in A.B+2, and is finally removed in >> A.B+3. So if I haven't read through the full release notes of each >> release nor enabled DeprecationWarnings, I end up having something >> broken each time I upgrade Django. >> > > 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? Sounds like the DeprecationWarnings give you just one version of advance notice. You would have to be (a) upgrading every version as it comes out, and (b) checking your log of warnings prior to every upgrade. Neither A.B nor A.B+1 will help you even if you check the warnings. So it would still require checking the full release notes every time, if you want to know about what's being deprecated. Seems a lot of annoying breakage to me. Python is frequently not upgraded release-by-release. I've had servers jump several versions at a time; my oldest server now is running 3.1.1 (and 2.6.4), so when it eventually gets upgraded, it'll probably jump to 3.3 or 3.4. Unless something's producing visible warnings all the way back to 3.1, removal in 3.4 has the potential to be surprising. ChrisA ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When to remove deprecated stuff
Hi, On Thu, Aug 22, 2013 at 1:00 PM, Petri Lehtinen 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) DeprecationWarning in A.B+2, and is finally removed in > A.B+3. I see two problems with this: 1) DeprecationWarnings should be generated as soon as the feature is deprecated (i.e. A.B, not A.B+2). Holding off the warnings is not helping anyone. 2) The deprecation period seems fixed and independent from the feature. IMHO the period should vary depending on what is being deprecated. Little known/used "features" could be deprecated in A.B and removed in A.B+1; common "features" can be deprecated in A.B and removed in A.B+n, with an n >= 2 (or even wait for A+1). > So if I haven't read through the full release notes of each > release nor enabled DeprecationWarnings, I end up having something > broken each time I upgrade Django. > Reading the release notes shouldn't be required -- DeprecationWarnings are already supposed to tell you what to change. If you have good test coverage this should happen automatically (at least with unittest), but even if you don't you should run your code with -Wa before upgrading (or test your code on the new version before upgrading Python/Django/etc. in production). Best Regards, Ezio Melotti > I hope the same will not start happening each time I upgrade Python. > When the removals happen on major version boundaries, it should be > more evident that something will break. Then people can enable > DepreationWarnings and test all the affected code thoroughly with the > new version before upgrading. > > Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When to remove deprecated stuff
On Aug 22, 2013, at 1:34 PM, Ezio Melotti wrote: > Hi, > > On Thu, Aug 22, 2013 at 1:00 PM, Petri Lehtinen 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) DeprecationWarning in A.B+2, and is finally removed in >> A.B+3. > > I see two problems with this: > 1) DeprecationWarnings should be generated as soon as the feature is > deprecated (i.e. A.B, not A.B+2). Holding off the warnings is not > helping anyone. > 2) The deprecation period seems fixed and independent from the > feature. IMHO the period should vary depending on what is being > deprecated. Little known/used "features" could be deprecated in A.B > and removed in A.B+1; common "features" can be deprecated in A.B and > removed in A.B+n, with an n >= 2 (or even wait for A+1). This isn't exactly accurate, it raises a PendingDeprecation warning in A.B, Deprecation in A.B+1, and removed in A.B+2. PendingDeprecation (In Django) was designed to be silent by default and Deprecation loud by default. That got messed up when Python silenced Deprecation warnings by default and we've had to resort to some ugliness to restore that behavior. > >> So if I haven't read through the full release notes of each >> release nor enabled DeprecationWarnings, I end up having something >> broken each time I upgrade Django. >> > > Reading the release notes shouldn't be required -- DeprecationWarnings > are already supposed to tell you what to change. > If you have good test coverage this should happen automatically (at > least with unittest), but even if you don't you should run your code > with -Wa before upgrading (or test your code on the new version before > upgrading Python/Django/etc. in production). > > Best Regards, > Ezio Melotti > >> I hope the same will not start happening each time I upgrade Python. >> When the removals happen on major version boundaries, it should be >> more evident that something will break. Then people can enable >> DepreationWarnings and test all the affected code thoroughly with the >> new version before upgrading. >> >> Petri > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/donald%40stufft.io - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When to remove deprecated stuff
On Thu, Aug 22, 2013 at 4:43 PM, R. David Murray wrote: > On Thu, 22 Aug 2013 16:45:29 +0300, Michael Foord > wrote: >> >> On 22 Aug 2013, at 14:00, Petri Lehtinen 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) DeprecationWarning in A.B+2, and is finally removed in >> > A.B+3. So if I haven't read through the full release notes of each >> > release nor enabled DeprecationWarnings, I end up having something >> > broken each time I upgrade Django. >> > >> >> 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 obviously differ): > > Putting in one big chunk of effort at a major release boundary is easier > to schedule than putting in a chunk of effort on *every* feature > release. IMHO there is a third (and better option) that you are missing. Assume I'm using A.B, and see some DeprecationWarnings. Now I have at least 1.5 years to fix them before A.B+1 is released, and once that happens there shouldn't be any warnings left so I can upgrade successfully. Once I do, more warnings will pop up, but then again I will have 1.5+ years to fix them. It seems to me that the problem only arises when the developers ignore (or possibly are unaware of) the warnings until it's time to upgrade. > More importantly, having it happen only at the major release > boundary means there's only one hard deadline every ten-ish years, rather > than a hard deadline every 1.5 years. > > [...] > > How does one judge what the optimal amount of change is? > > It would be great if we could figure out how to figure out what the > users want. We more or less have one user opinion so far, from Petri, > based on his experience as a Django user. We developers are also users, > of course, but our opinions are colored by our needs as developers as > well, so we aren't reliable judges. As I see it there are 3 groups: 1) developers writing libraries/frameworks/interpreters; 2) developers using these libraries/frameworks/interpreters; 3) end users using the applications wrote by the developers. The first group is responsible of warning the second group of the things that got deprecated and give them enough time to update their code. The second group is responsible to listen to the warnings and update their code accordingly. The third group is responsible to sit back and enjoy our hard work without seeing warnings/errors. Best Regards, Ezio Melotti > > --David > > PS: When thinking about this, remember that our effective policy for > (the second half of?) Python2 was to hold all the big cruft removal until > Python3. Even some stuff that was originally scheduled to be removed > sooner got left in. So our user base is currently used to things being > pretty stable from a deprecation/backward compatibility standpoint. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When to remove deprecated stuff
On Thu, Aug 22, 2013 at 7:45 PM, Donald Stufft wrote: > > On Aug 22, 2013, at 1:34 PM, Ezio Melotti wrote: > >> Hi, >> >> On Thu, Aug 22, 2013 at 1:00 PM, Petri Lehtinen 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) DeprecationWarning in A.B+2, and is finally removed in >>> A.B+3. >> >> I see two problems with this: >> 1) DeprecationWarnings should be generated as soon as the feature is >> deprecated (i.e. A.B, not A.B+2). Holding off the warnings is not >> helping anyone. >> 2) The deprecation period seems fixed and independent from the >> feature. IMHO the period should vary depending on what is being >> deprecated. Little known/used "features" could be deprecated in A.B >> and removed in A.B+1; common "features" can be deprecated in A.B and >> removed in A.B+n, with an n >= 2 (or even wait for A+1). > > This isn't exactly accurate, it raises a PendingDeprecation warning in A.B, > Deprecation in A.B+1, and removed in A.B+2. > > PendingDeprecation (In Django) was designed to be silent by default > and Deprecation loud by default. That got messed up when Python > silenced Deprecation warnings by default and we've had to resort to > some ugliness to restore that behavior. > So it's not much different from what we do now, except that we basically stopped using PendingDeprecationWarning -> DeprecationWarning and just use DeprecationWarnings from the beginning. I don't see many advantages in keeping the pending deprecation warnings silent for developers, as it just encourages procrastination :) One advantage is that under your scheme, one can assume that what shows up as deprecated (not pending deprecated) will be removed in the next version, so you could focus your work on them first, but this doesn't work for our scheme were a deprecated "feature" might stay there for a couple of versions. Maybe we should introduce a ``.removed_in`` attribute to DeprecationWarnings? We some times mention it in the deprecation message and the docs, but there's no way to get that information programmatically. Best Regards, Ezio Melotti >> >>> So if I haven't read through the full release notes of each >>> release nor enabled DeprecationWarnings, I end up having something >>> broken each time I upgrade Django. >>> >> >> Reading the release notes shouldn't be required -- DeprecationWarnings >> are already supposed to tell you what to change. >> If you have good test coverage this should happen automatically (at >> least with unittest), but even if you don't you should run your code >> with -Wa before upgrading (or test your code on the new version before >> upgrading Python/Django/etc. in production). >> >> Best Regards, >> Ezio Melotti >> >>> I hope the same will not start happening each time I upgrade Python. >>> When the removals happen on major version boundaries, it should be >>> more evident that something will break. Then people can enable >>> DepreationWarnings and test all the affected code thoroughly with the >>> new version before upgrading. >>> >>> Petri >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/donald%40stufft.io > > > - > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When to remove deprecated stuff
On Thu, 22 Aug 2013 20:00:14 +0200, Ezio Melotti wrote: > On Thu, Aug 22, 2013 at 4:43 PM, R. David Murray > wrote: > > On Thu, 22 Aug 2013 16:45:29 +0300, Michael Foord > > wrote: > >> > >> On 22 Aug 2013, at 14:00, Petri Lehtinen 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) DeprecationWarning in A.B+2, and is finally removed in > >> > A.B+3. So if I haven't read through the full release notes of each > >> > release nor enabled DeprecationWarnings, I end up having something > >> > broken each time I upgrade Django. > >> > > >> > >> 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 obviously differ): > > > > Putting in one big chunk of effort at a major release boundary is easier > > to schedule than putting in a chunk of effort on *every* feature > > release. > > IMHO there is a third (and better option) that you are missing. > > Assume I'm using A.B, and see some DeprecationWarnings. Now I have at > least 1.5 years to fix them before A.B+1 is released, and once that > happens there shouldn't be any warnings left so I can upgrade > successfully. Once I do, more warnings will pop up, but then again I > will have 1.5+ years to fix them. > > It seems to me that the problem only arises when the developers ignore > (or possibly are unaware of) the warnings until it's time to upgrade. I think you missed my point. 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 of ignoring deprecation warnings, then they have to do that work before their users can upgrade to the version where the feature is removed. So the pain exists in equal measure either way, with the same periodicity, only the timing of when the work is done is affected by whether or not you pay attention to deprecation warnings. And yes, you presumably have a more relaxed fix schedule and happier users if you pay attention to deprecation warnings, so you should do that (IMO). I'm asking if the bigger removals should be only on major version boundaries, thus allowing *more* time for that relaxed fix mode for the stuff that takes more work to fix. It does occur to me that this would mean we'd bikeshed about whether any given change was major or not...but we'd do that anyway, because we'd argue about h^h^h^h^h^h^h^h^h discuss how many releases to wait before actually removing it, depending on how disruptive it was likely to be. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 446 (make FD non inheritable) ready for a final review
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 run regulary the test suite on my virtual machines: Windows 7 SP1, Linux 3.2, FreeBSD 9 and OpenIndiana (close to Solaris 11), but also sometimes on OpenBSD 5.2. I don't expect major bugs, but you may find minor issues, especially on old operating systems. I don't have access to older systems. *** I collected the list of all threads related to the inheritance of file descriptors on python-dev since january 2013. I counted no more than 239 messages! Thank you all developers who contributed to these discussions and so helped me to write the PEP 433 and the PEP 446, especially Charles-François Natali and Richard Oudkerk! I read again all these messages, and I cannot "go backward" to the PEP 433. There are too many good reasons against adding a global variable (sys.getdefaultcloexec()), and adding a new inheritable parameter without changing the inheritance to non-inheritable does not solve issues listed in the Rationale of the PEP 446. At the beginning of the discussions, most developers already agreed that making file descriptors non-inheritable by default is the best choice. It took me some months to really understand all the consequences of changing the inheritance. I had also many technical issues because each operating system handles the inheritance of file descriptors differently, especially Windows vs UNIX. For atomic flags, there are differences even between minor versions of operating systems. For example, the O_CLOEXEC flag is only supported since Linux 2.6.23. We spend a lot of time to discuss each intermediate solution, but the conclusion is that no compromise can be found on an intermediate solution, only a radical change can solve the problem. [Python-Dev] Add "e" (close and exec) mode to open() (13 messages) Tue Jan 8 2013 http://mail.python.org/pipermail/python-dev/2013-January/123494.html [Python-Dev] Set close-on-exec flag by default in SocketServer (31) Wed Jan 9 2013 http://mail.python.org/pipermail/python-dev/2013-January/123552.html [Python-Dev] PEP 433: Add cloexec argument to functions creating file descriptors (27) Sun Jan 13 2013 http://mail.python.org/pipermail/python-dev/2013-January/123609.html [Python-Dev] Implementation of the PEP 433 (2) Fri Jan 25 2013 http://mail.python.org/pipermail/python-dev/2013-January/123684.html [Python-Dev] PEP 433: Choose the default value of the new cloexec parameter (37) Fri Jan 25 2013 http://mail.python.org/pipermail/python-dev/2013-January/123685.html [Python-Dev] PEP 433: second try (5) Tue Jan 29 2013 http://mail.python.org/pipermail/python-dev/2013-January/123763.html [Python-Dev] Release or not release the GIL (11) Fri Feb 1 2013 http://mail.python.org/pipermail/python-dev/2013-February/123780.html [Python-Dev] Status of the PEP 433? (2) Thu Feb 14 2013 http://mail.python.org/pipermail/python-dev/2013-February/124070.html [Python-Dev] PEP 446: Add new parameters to configure the inherance of files and for non-blocking sockets (24) Thu Jul 4 2013 http://mail.python.org/pipermail/python-dev/2013-July/127168.html [Python-Dev] Inherance of file descriptor and handles on Windows (PEP 446) (41) Wed Jul 24 2013 http://mail.python.org/pipermail/python-dev/2013-July/127509.html http://mail.python.org/pipermail/python-dev/2013-August/127791.html [Python-Dev] PEP 446: Open issues/questions (29) Sun Jul 28 2013 http://mail.python.org/pipermail/python-dev/2013-July/127626.html http://mail.python.org/pipermail/python-dev/2013-August/127728.html [Python-Dev] (New) PEP 446: Make newly created file descriptors non-inheritable (8) Tue Aug 6 2013 http://mail.python.org/pipermail/python-dev/2013-August/127805.html [Python-Dev] PEP 446: issue with sockets (9) Wed Aug 21 2013 http://mail.python.org/pipermail/python-dev/2013-August/128045.html Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When to remove deprecated stuff
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 of ignoring deprecation warnings, then they have to do that > work before their users can upgrade to the version where the feature > is removed. So the pain exists in equal measure either way, with the > same periodicity, only the timing of when the work is done is affected > by whether or not you pay attention to deprecation warnings. This is exactly correct analysis. Changing the DeprecationWarning policy is not going to save anybody any work, and it's not likely to silence the grumbling. It's the feature removal that causes the extra work and that is what causes the complaints. > And yes, you presumably have a more relaxed fix schedule and > happier users if you pay attention to deprecation warnings, so you > should do that (IMO). Sure, but human nature doesn't work that way. Some people will, others won't, and the latter are likely to think they have reason to complain. > I'm asking if the bigger removals should be only on major version > boundaries, thus allowing *more* time for that relaxed fix mode for the > stuff that takes more work to fix. My take is that it's not going to help that much. You just don't know what's going to take more work to fix. A trivial-to-fix problem in a proprietary library abandoned by its developer can take a complete rewrite of your program. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When to remove deprecated stuff
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 obviously differ): > > Putting in one big chunk of effort at a major release boundary is easier > to schedule than putting in a chunk of effort on *every* feature > release. More importantly, having it happen only at the major release > boundary means there's only one hard deadline every ten-ish years, rather > than a hard deadline every 1.5 years. > > Expecting things to break when you switch to the new feature release > makes one view feature releases with dread rather than excitement. > > This applies whether or not one is testing with deprecation warnings on. > Yes, there's a little less pressure if you are making the fixes on > the deprecation release boundary, because you can always ship the > code anyway if it is winds up being too big of a bear, so you have more > scheduling flexibility. But you still face the *psychological* hurdle of > "feature release upgrade...will need to fix the all the things they've > deprecated...let's put that off". Especially since what we are talking > about here is the *big* cruft, and thus more likely to be a pain to fix. These are my thoughts exactly. Maybe I exaggerated a bit about Django. I was slightly unaware of the deprecation policy when Django 1.3 came out (IIRC it was the first release that actually removed deprecated stuff after 1.0). Nowadays I read release notes carefully and do what's needed, and nothing has broken badly ever since. What's really bothering me is that I have to change something in my code every time I upgrade Django. So as David said, it's more like "sigh, a new feature release again" than "yay, new cool features!". Or actually, it's a combination of both because I really want the new features. Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
