On 8/18/2012 5:27 PM, Antoine Pitrou wrote:
On Sat, 18 Aug 2012 17:17:14 -0400
Terry Reedy wrote:
The issue came up in python-list about string operations being slower in
3.3. (The categorical claim is false as some things are actually
faster.) Some things I understand, this one I do not.
Win7
On Sat, 18 Aug 2012 17:17:14 -0400, Terry Reedy wrote:
> print(timeit("a.encode()", "a = 'a'*1000"))
> # 1.5 in 3.2, .26 in 3.3
>
> print(timeit("a.encode(encoding='utf-8')", "a = 'a'*1000"))
> # 1.7 in 3.2, .51 in 3.3
>
> This is one of the 3.3 improvements. But since the results are equal:
> (
Zitat von Terry Reedy :
Is this worth a tracker issue (I searched and could not find one) or
is there a known and un-fixable cause?
There is a third option: it's not known, but it's also unimportant.
I'd say posting it to python-dev is enough: either there is somebody
with sufficient time an
On Sat, 18 Aug 2012 17:17:14 -0400
Terry Reedy wrote:
> The issue came up in python-list about string operations being slower in
> 3.3. (The categorical claim is false as some things are actually
> faster.) Some things I understand, this one I do not.
>
> Win7-64, 3.3.0b2 versus 3.2.3
> print(t
The issue came up in python-list about string operations being slower in
3.3. (The categorical claim is false as some things are actually
faster.) Some things I understand, this one I do not.
Win7-64, 3.3.0b2 versus 3.2.3
print(timeit("c in a", "c = '…'; a = 'a'*1000+c")) # ord(c) = 8230
# .6
On 8/18/2012 11:47 AM, MRAB wrote:
I vote -0. The issue can also be addressed with a small and simple
helper function that wraps urlparse and compares the query parameter. Or
you cann urlencode() with `sorted(qs.items)` instead of `qs` in the
application.
Hm. That's actually a good point.
Se
On Saturday, August 18, 2012, MRAB wrote:
> On 18/08/2012 18:34, Guido van Rossum wrote:
>
>> On Sat, Aug 18, 2012 at 6:28 AM, Christian Heimes
>> wrote:
>>
>>> Am 17.08.2012 21:27, schrieb Guido van Rossum:
>>>
I wonder if it wouldn't make sense to change urlencode() to generate
URLs t
On 18/08/2012 18:34, Guido van Rossum wrote:
On Sat, Aug 18, 2012 at 6:28 AM, Christian Heimes wrote:
Am 17.08.2012 21:27, schrieb Guido van Rossum:
I wonder if it wouldn't make sense to change urlencode() to generate
URLs that don't depend on the hash order, for all versions of Python
that su
On Sat, Aug 18, 2012 at 6:28 AM, Christian Heimes wrote:
> Am 17.08.2012 21:27, schrieb Guido van Rossum:
>> I wonder if it wouldn't make sense to change urlencode() to generate
>> URLs that don't depend on the hash order, for all versions of Python
>> that support PYTHONHASHSEED? It seems a one-l
Am 17.08.2012 21:27, schrieb Guido van Rossum:
> I wonder if it wouldn't make sense to change urlencode() to generate
> URLs that don't depend on the hash order, for all versions of Python
> that support PYTHONHASHSEED? It seems a one-line fix:
>
> query = query.items()
>
> with this:
>
On 18 August 2012 02:23, Stephen J. Turnbull wrote:
> 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
On Sat, 18 Aug 2012 14:23:13 +0900
"Stephen J. Turnbull" wrote:
> 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. O
Guido van Rossum wrote:
> I wonder if it wouldn't make sense to change urlencode() to generate
> URLs that don't depend on the hash order, for all versions of Python
> that support PYTHONHASHSEED? It seems a one-line fix:
>
> query = query.items()
>
> with this:
>
> query = sorted(query.items()
13 matches
Mail list logo
