Joao S. O. Bueno writes:
> I don't think this behavior is only desirable to unit tests: having
> URL's been formed in predictable way a good thing in any way one
> thinks about it.
Especially if you're a hacker. One more thing you may be able to use
against careless sites that don't expect t
On 17 August 2012 18:52, Chris Angelico wrote:
> On Sat, Aug 18, 2012 at 5:27 AM, Guido van Rossum wrote:
>> I just fixed a unittest for some code used at Google that was
>> comparing a url generated by urllib.encode() to a fixed string. The
>> problem was caused by turning on PYTHONHASHSEED=1. B
On Sat, Aug 18, 2012 at 5:27 AM, Guido van Rossum wrote:
> I just fixed a unittest for some code used at Google that was
> comparing a url generated by urllib.encode() to a fixed string. The
> problem was caused by turning on PYTHONHASHSEED=1. Because of this,
> the code under test would generate
Thanks, I filed http://bugs.python.org/issue15719 to track this.
On Fri, Aug 17, 2012 at 12:50 PM, "Martin v. Löwis" wrote:
> On 17.08.2012 21:27, Guido van Rossum wrote:
>> query = sorted(query.items())
>>
>> This would not prevent breakage of unit tests, but it would make a
>> much simp
On 17.08.2012 21:27, Guido van Rossum wrote:
> query = sorted(query.items())
>
> This would not prevent breakage of unit tests, but it would make a
> much simpler fix possible: simply sort the parameters in the URL.
>
> Thoughts?
Sounds good. For best backwards compatibility, I'd restrict
Only if it is not an OrderedDict
> query = sorted(query.items())
>
> This would not prevent breakage of unit tests, but it would make a
> much simpler fix possible: simply sort the parameters in the URL.
___
Python-Dev mailing list
Python-Dev@pyt
I just fixed a unittest for some code used at Google that was
comparing a url generated by urllib.encode() to a fixed string. The
problem was caused by turning on PYTHONHASHSEED=1. Because of this,
the code under test would generate a textually different URL each time
the test was run, but the inte
On Fri, Aug 17, 2012 at 06:50:09AM -0700, Stefan Krah wrote:
> R. David Murray wrote:
> > > --- a/Lib/test/test_cmath.pyThu Aug 16 22:14:43 2012 +0200
> > > +++ b/Lib/test/test_cmath.pyFri Aug 17 07:54:05 2012 +
> >
> > Open an issue on the tracker and make mark.dickinson (and maybe s
ACTIVITY SUMMARY (2012-08-10 - 2012-08-17)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3640 (+52)
closed 23856 (+48)
total 27496 (+100)
Open issues wi
R. David Murray wrote:
> > --- a/Lib/test/test_cmath.pyThu Aug 16 22:14:43 2012 +0200
> > +++ b/Lib/test/test_cmath.pyFri Aug 17 07:54:05 2012 +
>
> Open an issue on the tracker and make mark.dickinson (and maybe skrah)
> nosy.
I think this issue covers the problem:
http://bugs.pyth
On Fri, 17 Aug 2012 04:00:50 -0400, Trent Nelson wrote:
> This is the patch I came up with against test_cmath.py:
>
> xenon% hg diff Lib/test/test_cmath.py
> diff -r ce49599b9fdf Lib/test/test_cmath.py
> --- a/Lib/test/test_cmath.pyThu Aug 16 22:14:43 2012 +0200
> +++ b/Lib/test/test_cmat
The Mountain Lion build slave I set up earlier this evening fails on
test_cmath:
==
FAIL: test_specific_values (test.test_cmath.CMathTests)
--
12 matches
Mail list logo