Backward-incompatible change to random.randrange in 2.7.6
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://hg.python.org/cpython/rev/b1e94e332ec8 Do we really want to change an undocumented-but-effectively-public API in a late-in-the-release-cycle third dot release? It caused, ZODB's tests to fail, for instance. While the docstring said, "Don't use the 'int', 'default', and 'maxwidth' arguments", their names were not intrinsically private. In particular, passing in the 'int' argument was a strategy for generating compatible long values when straddling Python 2.x / Python 3.x. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKwlXAACgkQ+gerLs4ltQ60DQCgzlO8mHMXQ0vsHNpS9GKwjpmD G6oAoMIjtrKkGTlFj0b9Tfdj5BCu1rYS =GxuS -----END PGP SIGNATURE-----
This really seems a case of ZODB depending on internals where it really, really should have known better. Calling this "a de-facto public interface" seems way too far a stretch of the intention. And please don't fix it by version-testing and using a different argument name... On Tue, Dec 17, 2013 at 10:18 AM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
http://hg.python.org/cpython/rev/b1e94e332ec8
Do we really want to change an undocumented-but-effectively-public API in a late-in-the-release-cycle third dot release? It caused, ZODB's tests to fail, for instance.
While the docstring said, "Don't use the 'int', 'default', and 'maxwidth' arguments", their names were not intrinsically private. In particular, passing in the 'int' argument was a strategy for generating compatible long values when straddling Python 2.x / Python 3.x.
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKwlXAACgkQ+gerLs4ltQ60DQCgzlO8mHMXQ0vsHNpS9GKwjpmD G6oAoMIjtrKkGTlFj0b9Tfdj5BCu1rYS =GxuS -----END PGP SIGNATURE-----
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/17/2013 01:40 PM, Guido van Rossum wrote:
This really seems a case of ZODB depending on internals where it really, really should have known better. Calling this "a de-facto public interface" seems way too far a stretch of the intention. And please don't fix it by version-testing and using a different argument name...
The usage is *ancient*: Jeremy checked it in 2001-10-05: https://github.com/zopefoundation/ZODB/commit/fd1653580ca67bdc281fb8c54662c9... The comment about "do not pass the 'int' or 'default' arguments" goes back to at least the 'whrandom.py' module in 1.5.2. ;) Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKwn7QACgkQ+gerLs4ltQ4WzACeOMXqg5Jg8ck3vK3cCDuTgKSS 8GwAn0yR8ukdQTh5Wo0jGDHq/AIgu+Yg =fTUf -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Dec 17, 2013, at 01:18 PM, Tres Seaver wrote:
http://hg.python.org/cpython/rev/b1e94e332ec8
Do we really want to change an undocumented-but-effectively-public API in a late-in-the-release-cycle third dot release? It caused, ZODB's tests to fail, for instance.
While the docstring said, "Don't use the 'int', 'default', and 'maxwidth' arguments", their names were not intrinsically private. In particular, passing in the 'int' argument was a strategy for generating compatible long values when straddling Python 2.x / Python 3.x.
Being quite sensitive to complaints about API breaks in patch releases, it does seem like a bad idea to change these in a backward incompatible way. It's true the docstring warns against it, and that the module does not document those arguments, but they're still there and changing them breaks existing code. That should be enough to revert and rewrite the change. I don't think the API *has* to change in a backward incompatible way either. The methods could be given **kws with a bit of hackery to figure out whether the old API was being used (keys: int, default, maxwidth) or the new API was being used (keys: _int and _maxwidth). Yeah it's ugly, but we serve our users better by doing it that way. Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSsJ4yAAoJEBJutWOnSwa/7EsP/1P3VaaeWdLnWkQKa06e4TpY oXHG3YUMAQ4AjrBFTc5KL1GQtSkg1m6pQKZf937XYhi9d4xfwbaSBqCBWYPkNdrx DR2Ix0Y/HwVPQvlqgfLWPS6TaZIrA2ssCVoOgWL2kmX+5KugIUy3O521OOre14jo jCQZTOL2sloT+/TlX1PSImYRrJnK9yklW0CW13OVnj5BsvjzQPtsL0z1ueSrebqu awTRCI7O8gpBcw7vcXnB6ZAfuA4urLQ+AnBXF1p5Rsxs3tGW9HS7L+QYWBM7sktV Hmb5ZIdH+4+gkCws2LSowt+06M3WEyLkGhwOH1gNU3WTgywcJ4L9sh7WwLZN5eCe Wz37LQ1fVFjpJhX2zOtI6djqL5r+6xpBxtuig0ezNJbAc1mhhvkPkTjMyvXqQzwX HJQ7OMthiHqVnNJRZQZs4tSeCPgRDkDSNe/RWSyh6gYr6Gn6wwDcbW20RrbbbU4y eKyY2VHQ0MKD283HVb3nfgelN96OgqWbpG/uk6mRPwPU1oIUyDDuhyyzNabggTSV n97lPsHvOJyPehKdu+QKxpFULlX6KEmTCLJsUIWsjMCVIUnHjobkpOqW20KveLr+ cPcSHDGIPKv4qnFJuihYWBz9NPbUT2xebaP02bL7Wu5UVDFxQ3t0P/wuhLoNjRzU vkUJ8m7CnRDFGuGPy6NQ =lw3q -----END PGP SIGNATURE-----
[Barry]
... I don't think the API *has* to change in a backward incompatible way either. The methods could be given **kws with a bit of hackery to figure out whether the old API was being used (keys: int, default, maxwidth) or the new API was being used (keys: _int and _maxwidth). Yeah it's ugly, but we serve our users better by doing it that way.
-1. The speed of randrange() is crucial for many applications; indeed, that's the only reason it abused default arguments to begin with (i.e., to make `int` et alia fast local lookups). Digging through a dict to guess which API was invoked would ruin that. And the ZODB tests in question deserve whatever they get ;-)
On Tue, 17 Dec 2013 13:18:25 -0500 Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
http://hg.python.org/cpython/rev/b1e94e332ec8
Do we really want to change an undocumented-but-effectively-public API in a late-in-the-release-cycle third dot release? It caused, ZODB's tests to fail, for instance.
Given the change doesn't seem to bring any visible change for users (either performance or robustness), I think it would be safe to revert it *in 2.7*. Of course Zope's practice is still rather bad here... Regards Antoine.
2013/12/17 Antoine Pitrou <solipsis@pitrou.net>:
On Tue, 17 Dec 2013 13:18:25 -0500 Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
http://hg.python.org/cpython/rev/b1e94e332ec8
Do we really want to change an undocumented-but-effectively-public API in a late-in-the-release-cycle third dot release? It caused, ZODB's tests to fail, for instance.
Given the change doesn't seem to bring any visible change for users (either performance or robustness), I think it would be safe to revert it *in 2.7*.
I agree with Antoine. It's better not to break even morally-broken programs like the zope tests in 2.7.x if it doesn't win anything. -- Regards, Benjamin
Isn't changing it in 2.7.6 which is already released and then reverting in 2.7.7 worse? Either way 2.7.6 will have this change and be in the wild and broken for people who depend on it
On Dec 17, 2013, at 5:54 PM, Benjamin Peterson <benjamin@python.org> wrote:
2013/12/17 Antoine Pitrou <solipsis@pitrou.net>:
On Tue, 17 Dec 2013 13:18:25 -0500 Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
http://hg.python.org/cpython/rev/b1e94e332ec8
Do we really want to change an undocumented-but-effectively-public API in a late-in-the-release-cycle third dot release? It caused, ZODB's tests to fail, for instance.
Given the change doesn't seem to bring any visible change for users (either performance or robustness), I think it would be safe to revert it *in 2.7*.
I agree with Antoine. It's better not to break even morally-broken programs like the zope tests in 2.7.x if it doesn't win anything.
-- Regards, Benjamin _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io
Mostly yes, but at least you could tell people to upgrade straight to 2.7.7 and skip 2.7.6. 2013/12/17 Donald Stufft <donald@stufft.io>:
Isn't changing it in 2.7.6 which is already released and then reverting in 2.7.7 worse? Either way 2.7.6 will have this change and be in the wild and broken for people who depend on it
On Dec 17, 2013, at 5:54 PM, Benjamin Peterson <benjamin@python.org> wrote:
2013/12/17 Antoine Pitrou <solipsis@pitrou.net>:
On Tue, 17 Dec 2013 13:18:25 -0500 Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
http://hg.python.org/cpython/rev/b1e94e332ec8
Do we really want to change an undocumented-but-effectively-public API in a late-in-the-release-cycle third dot release? It caused, ZODB's tests to fail, for instance.
Given the change doesn't seem to bring any visible change for users (either performance or robustness), I think it would be safe to revert it *in 2.7*.
I agree with Antoine. It's better not to break even morally-broken programs like the zope tests in 2.7.x if it doesn't win anything.
-- Regards, Benjamin _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io
-- Regards, Benjamin
18.12.13 04:40, Benjamin Peterson написав(ла):
Mostly yes, but at least you could tell people to upgrade straight to 2.7.7 and skip 2.7.6.
It'll make the people to postpone the upgrade to 2.7.6 (which fixes many security bugs) until 2.7.7 release, instead of correcting their morally-broken programs.
On Wed, Dec 18, 2013 at 8:43 PM, Serhiy Storchaka <storchaka@gmail.com> wrote:
18.12.13 04:40, Benjamin Peterson написав(ла):
Mostly yes, but at least you could tell people to upgrade straight to 2.7.7 and skip 2.7.6.
It'll make the people to postpone the upgrade to 2.7.6 (which fixes many security bugs) until 2.7.7 release, instead of correcting their morally-broken programs.
If this is considered enough breakage to be a problem, would it be possible to issue a 2.7.6.1 or 2.7.6+fixed release that's identical to 2.7.6 but with this change reverted? It'd be a minor mess, but then people would still get those security fixes, and it means not breaking stuff in a point release. ChrisA
On 18 December 2013 20:17, Chris Angelico <rosuav@gmail.com> wrote:
On Wed, Dec 18, 2013 at 8:43 PM, Serhiy Storchaka <storchaka@gmail.com> wrote:
18.12.13 04:40, Benjamin Peterson написав(ла):
Mostly yes, but at least you could tell people to upgrade straight to 2.7.7 and skip 2.7.6.
It'll make the people to postpone the upgrade to 2.7.6 (which fixes many security bugs) until 2.7.7 release, instead of correcting their morally-broken programs.
If this is considered enough breakage to be a problem, would it be possible to issue a 2.7.6.1 or 2.7.6+fixed release that's identical to 2.7.6 but with this change reverted? It'd be a minor mess, but then people would still get those security fixes, and it means not breaking stuff in a point release.
If we revert it, it means we do 2.7.7 ASAP so that *everyone* can just skip straight to 2.7.7. That kind of user visible change shouldn't have been made in a point release, regardless of what the docs said. It just isn't worth the risk of breaking the code of people that are relying on what's possible rather than what the docs say. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
BTW, I bet a lavish dinner at PyCon that it is *only* Zope/ZODB that does this. In the time we added this bogus dependency on undocumented parameters, the PythonLabs team was at Zope and we didn't always get our boundaries straight. On Wed, Dec 18, 2013 at 2:51 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 18 December 2013 20:17, Chris Angelico <rosuav@gmail.com> wrote:
On Wed, Dec 18, 2013 at 8:43 PM, Serhiy Storchaka <storchaka@gmail.com> wrote:
18.12.13 04:40, Benjamin Peterson написав(ла):
Mostly yes, but at least you could tell people to upgrade straight to 2.7.7 and skip 2.7.6.
It'll make the people to postpone the upgrade to 2.7.6 (which fixes many security bugs) until 2.7.7 release, instead of correcting their morally-broken programs.
If this is considered enough breakage to be a problem, would it be possible to issue a 2.7.6.1 or 2.7.6+fixed release that's identical to 2.7.6 but with this change reverted? It'd be a minor mess, but then people would still get those security fixes, and it means not breaking stuff in a point release.
If we revert it, it means we do 2.7.7 ASAP so that *everyone* can just skip straight to 2.7.7.
That kind of user visible change shouldn't have been made in a point release, regardless of what the docs said. It just isn't worth the risk of breaking the code of people that are relying on what's possible rather than what the docs say.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
But who could forget njzrs' wasp UAV software line 107, using int=float? https://github.com/nzjrs/wasp/blob/master/sw/groundstation/wasp/__init__.py#... On Wed, Dec 18, 2013 at 10:49 AM, Guido van Rossum <guido@python.org> wrote:
BTW, I bet a lavish dinner at PyCon that it is *only* Zope/ZODB that does this. In the time we added this bogus dependency on undocumented parameters, the PythonLabs team was at Zope and we didn't always get our boundaries straight.
On Wed, Dec 18, 2013 at 2:51 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 18 December 2013 20:17, Chris Angelico <rosuav@gmail.com> wrote:
On Wed, Dec 18, 2013 at 8:43 PM, Serhiy Storchaka <storchaka@gmail.com> wrote:
18.12.13 04:40, Benjamin Peterson написав(ла):
Mostly yes, but at least you could tell people to upgrade straight to 2.7.7 and skip 2.7.6.
It'll make the people to postpone the upgrade to 2.7.6 (which fixes many security bugs) until 2.7.7 release, instead of correcting their morally-broken programs.
If this is considered enough breakage to be a problem, would it be possible to issue a 2.7.6.1 or 2.7.6+fixed release that's identical to 2.7.6 but with this change reverted? It'd be a minor mess, but then people would still get those security fixes, and it means not breaking stuff in a point release.
If we revert it, it means we do 2.7.7 ASAP so that *everyone* can just skip straight to 2.7.7.
That kind of user visible change shouldn't have been made in a point release, regardless of what the docs said. It just isn't worth the risk of breaking the code of people that are relying on what's possible rather than what the docs say.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/dholth%40gmail.com
On Wed, 18 Dec 2013 11:31:47 -0500 Daniel Holth <dholth@gmail.com> wrote:
But who could forget njzrs' wasp UAV software line 107, using int=float? https://github.com/nzjrs/wasp/blob/master/sw/groundstation/wasp/__init__.py#...
And the purpose is quite Pythonesque: """ Generates a noisy random walk """ Regards Antoine.
[Daniel Holth]
But who could forget njzrs' wasp UAV software line 107, using int=float? https://github.com/nzjrs/wasp/blob/master/sw/groundstation/wasp/__init__.py#...
I could forget it ;-) The remarkable thing about the two instances of: random.randrange(0.0,1.0, int=float) in that file is that they're obscure and inefficient ways to spell: random.random() Which reminds me. I used to think there was no such thing as a stupid question. Then I discovered Stack Overflow ;-)
On Dec 18, 2013 11:54 AM, "Tim Peters" <tim.peters@gmail.com> wrote:
[Daniel Holth]
But who could forget njzrs' wasp UAV software line 107, using int=float? https://github.com/nzjrs/wasp/blob/master/sw/groundstation/wasp/__init__.py#...
I could forget it ;-) The remarkable thing about the two instances of:
random.randrange(0.0,1.0, int=float)
in that file is that they're obscure and inefficient ways to spell:
random.random()
You can keep your "premature optimizations" thank you :-)
participants (12)
-
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Chris Angelico -
Daniel Holth -
Donald Stufft -
Ethan Furman -
Guido van Rossum -
Nick Coghlan -
Serhiy Storchaka -
Tim Peters -
Tres Seaver