Re: [Python-Dev] order of Misc/ACKS
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 declined to open it. /larry/ ___ 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] order of Misc/ACKS
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 examples were already given in this thread. The > Han-using languages also have this problem, and Japanese is > nondetermistic all by itself (there are kanji names which for > historical reasons are pronounced in several different ways, and > therefore cannot be placed in phonetic order without additional > information). > > The sensible thing is to just sort in Unicode code point order, I > think. The sensible thing is to accept that there is no solution, and to stop worrying. Georg ___ 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] order of Misc/ACKS
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.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] order of Misc/ACKS
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 order acceptable by everyone. >> >> Yes, it is. The examples were already given in this thread. The >> Han-using languages also have this problem, and Japanese is >> nondetermistic all by itself (there are kanji names which for >> historical reasons are pronounced in several different ways, and >> therefore cannot be placed in phonetic order without additional >> information). >> >> The sensible thing is to just sort in Unicode code point order, I >> think. > > The sensible thing is to accept that there is no solution, and to stop > worrying. The file could use the default collation order, that way it'd be incorrectly sorted for everybody. ___ 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] Merging 3.2 to 3.3 is messy because "Misc/NEWS"
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 log viewer). For Misc/NEWS, I have written a merge tool that opens Vim with the destination file in a pane and a diff containing the changes on the other branch in another pane. So instead of getting many diff hunks between 3.2 and 3.3, I get the 3.3 NEWS on the left and a diff corresponding to the 3.2 changes I’m merging on the right, so I can copy-paste NEWS entries. There may be duplicates when merging again after a push race, but it’s still convenient. It’s a shell script hard-coded to use Vim; I consider these bugs and intend to fix them to make it more widely useful. I initially wrote this script to handle translation branches. If you manage text and translations with Mercurial, say English content in the default branch and a French translation in branch named 'fr', when you change the English text and merge, a standard merge tool is nearly useless, as the two files are near-completely different. With my tool, you get the French file on the left and a diff of the English changes on the right, and on you go. Please help yourself, and don’t forget to look at the README for configuration information: https://bitbucket.org/Merwok/scripts-hg Ezio and I chatted a bit about his on IRC and he may try to write a Python parser for Misc/NEWS in order to write a fully automated merge tool. Cheers ___ 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] documenting the Hg commit message hooks in the devguide
>> 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 description into the devguide would be a good >> idea, probably here: >> http://docs.python.org/devguide/committing.html#commit-messages-and-news-entries >> >> Any objections/alternative ideas? > > No objections, it's a good idea. > Alright. Created issue 13388 to track this. Eli ___ 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] Hashable memoryviews
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 comparison:
>>> b"" == memoryview(b"")
True
If the original object providing the buffer is hashable, then it
seems to make sense for the memoryview object to be hashable. This came
while porting Twisted to Python 3.
What do you think?
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] Hashable memoryviews
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 recent call last):
> File "", line 1, in
> TypeError: unhashable type: 'memoryview'
>
> Compare with Python 2.7:
>
hash(buffer(""))
> 0
>
> memoryviews already support equality comparison:
>
b"" == memoryview(b"")
> True
>
> If the original object providing the buffer is hashable, then it
> seems to make sense for the memoryview object to be hashable. This came
> while porting Twisted to Python 3.
>
> What do you think?
>
> 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/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
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] Hashable memoryviews
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 algorithm: 1) try to calculate the original object's hash; if it fails, consider the memoryview unhashable (the buffer is probably mutable) 2) otherwise, calculate the memoryview's hash with the same algorithm as bytes objects (so that it's compatible with equality comparisons) 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] Hashable memoryviews
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 the memoryview > is read-only. > > I would propose the following algorithm: > 1) try to calculate the original object's hash; if it fails, consider > the memoryview unhashable (the buffer is probably mutable) > 2) otherwise, calculate the memoryview's hash with the same algorithm > as bytes objects (so that it's compatible with equality comparisons) Having a memory view be hashable if the object it references is hashable seems analogous to the way tuples are hashable if everything they reference is hashable, so +0 from me. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Hashable memoryviews
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:
>
> >>> 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 comparison:
>
> >>> b"" == memoryview(b"")
> True
>
> If the original object providing the buffer is hashable, then it
> seems to make sense for the memoryview object to be hashable. This came
> while porting Twisted to Python 3.
>
> What do you think?
>
> 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] Hashable memoryviews
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. >> >> Only if the original object is itself mutable, otherwise the memoryview >> is read-only. >> >> I would propose the following algorithm: >> 1) try to calculate the original object's hash; if it fails, consider >> the memoryview unhashable (the buffer is probably mutable) >> 2) otherwise, calculate the memoryview's hash with the same algorithm >> as bytes objects (so that it's compatible with equality comparisons) > > Having a memory view be hashable if the object it references is > hashable seems analogous to the way tuples are hashable if everything > they reference is hashable, so +0 from me. Yeah, that's ok with me too. -- --Guido van Rossum (python.org/~guido) ___ 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
