On 11/11/2011 11:03 PM, Stephen J. Turnbull wrote:
The sensible thing is to just sort in Unicode code point order, I
think.
I was going to suggest the official Unicode Collation Algorithm:
http://unicode.org/reports/tr10/
But I peeked in the can, saw it was chock-a-block with worms, and
d
Am 12.11.2011 08:03, schrieb Stephen J. Turnbull:
> Eli Bendersky writes:
>
> > special locale. It makes me wonder whether it's possible to have a
> > contradiction in the ordering, i.e. have a set of names that just
> > can't be sorted in any order acceptable by everyone.
>
> Yes, it is. The
On Nov 12, 2011, at 04:03 PM, Stephen J. Turnbull wrote:
>The sensible thing is to just sort in Unicode code point order, I
>think.
M-x sort-lines-by-unicode-point-order RET
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
On 2011-11-12, at 10:24 , Georg Brandl wrote:
> Am 12.11.2011 08:03, schrieb Stephen J. Turnbull:
>> Eli Bendersky writes:
>>
>>> special locale. It makes me wonder whether it's possible to have a
>>> contradiction in the ordering, i.e. have a set of names that just
>>> can't be sorted in any orde
Hi,
My usual merge tool is vimdiff, with a little configuration so that it
shows only two panes instead of three (destination file on the left,
file from the other branch on the right, and if I need to compare either
with the common ancestor to see which chunks I want from each file, I
use a
>> Our Hg repo has some useful hooks on commit messages that allow to
>> specify which issue to notify for commits, and which issue to close.
>> AFAIU, it's currently documented only in the code of the hook
>> (http://hg.python.org/hooks/file/tip/hgroundup.py).
>>
>> I think adding a short descript
Hello everyone and Benjamin,
Currently, memoryview objects are unhashable:
>>> hash(memoryview(b""))
Traceback (most recent call last):
File "", line 1, in
TypeError: unhashable type: 'memoryview'
Compare with Python 2.7:
>>> hash(buffer(""))
0
memoryviews already support equality comparis
Aren't memoryview objects mutable? I think that the underlying memory
can change, so it shouldn't be hashable.
On Sat, Nov 12, 2011 at 4:23 PM, Antoine Pitrou wrote:
>
> Hello everyone and Benjamin,
>
> Currently, memoryview objects are unhashable:
>
hash(memoryview(b""))
> Traceback (most r
On Sat, 12 Nov 2011 17:15:08 -0800
Guido van Rossum wrote:
> Aren't memoryview objects mutable? I think that the underlying memory
> can change, so it shouldn't be hashable.
Only if the original object is itself mutable, otherwise the memoryview
is read-only.
I would propose the following algori
On Sun, Nov 13, 2011 at 11:19 AM, Antoine Pitrou wrote:
> On Sat, 12 Nov 2011 17:15:08 -0800
> Guido van Rossum wrote:
>> Aren't memoryview objects mutable? I think that the underlying memory
>> can change, so it shouldn't be hashable.
>
> Only if the original object is itself mutable, otherwise
Thinking of it, an alternative would be to implement lazy slices of
bytes objects (Twisted uses buffer() for zero-copy slices).
Regards
Antoine.
On Sun, 13 Nov 2011 01:23:59 +0100
Antoine Pitrou wrote:
>
> Hello everyone and Benjamin,
>
> Currently, memoryview objects are unhashable:
>
> >
On Sat, Nov 12, 2011 at 5:40 PM, Nick Coghlan wrote:
> On Sun, Nov 13, 2011 at 11:19 AM, Antoine Pitrou wrote:
>> On Sat, 12 Nov 2011 17:15:08 -0800
>> Guido van Rossum wrote:
>>> Aren't memoryview objects mutable? I think that the underlying memory
>>> can change, so it shouldn't be hashable.
>
12 matches
Mail list logo
