Re: [Python-ideas] PEP 540: Add a new UTF-8 mode

On Fri, Jan 06, 2017 at 02:54:49AM +0100, Victor Stinner wrote: > Let's say that you have the filename b'nonascii\xff': it's decoded as > 'nonascii\xdcff' by the UTF-8 mode. How do GUIs handle such filename? > (I don't know the answer, it's a real question ;-)) I ran this in Python 2.7 to create

Re: [Python-ideas] incremental hashing in __hash__

On Thu, Jan 5, 2017 at 9:10 PM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Paul Moore writes: > > > The debate here regarding tuple/frozenset indicates that there may not > > be a "standard way" of hashing an iterable (should order matter?). > > If part of the data

Re: [Python-ideas] PEP 540: Add a new UTF-8 mode

2017-01-06 3:10 GMT+01:00 Stephen J. Turnbull : > The point of this, I suppose, is that piping to xargs works by > default. Please read the second version (latest) version of my PEP 540 which contains a new "Use Cases" section which helps to define issues and

Re: [Python-ideas] PEP 540: Add a new UTF-8 mode

Victor Stinner writes: > Python 3.6 is not exactly in the first or the later category: "it > depends". > > To read data from the operating system, Python 3.6 behaves in "UNIX > mode": os.listdir() *does* return invalid filenames, it uses a funny > encoding using surrogates. > > To write

Re: [Python-ideas] incremental hashing in __hash__

Paul Moore writes: > The debate here regarding tuple/frozenset indicates that there may not > be a "standard way" of hashing an iterable (should order matter?). If part of the data structure, yes, if an implementation accident, no. > Although I agree that assuming order matters is a

Re: [Python-ideas] PEP 540: Add a new UTF-8 mode

2017-01-06 2:15 GMT+01:00 INADA Naoki : >>> Always use UTF-8 (...) >>Please don't! (...) > > For stdio (including console), PYTHONIOENCODING can be used for > supporting legacy system. > e.g. `export PYTHONIOENCODING=$(locale charmap)` The problem with ignoring the

Re: [Python-ideas] PEP 540: Add a new UTF-8 mode

Ok, I modified my PEP: the POSIX locale now enables the UTF-8 mode. 2017-01-05 18:10 GMT+01:00 Victor Stinner : > A common request is that "Python just works" without having to pass a > command line option or set an environment variable. Maybe the default > behaviour

Re: [Python-ideas] PEP 540: Add a new UTF-8 mode

>> Always use UTF-8 >> >> >> Python already always use the UTF-8 encoding on Mac OS X, Android and >> Windows. >> Since UTF-8 became the defacto encoding, it makes sense to always use it on >> all >> platforms with any locale. > >Please don't! I use different locales and

Re: [Python-ideas] PEP 540: Add a new UTF-8 mode

On Thu, Jan 05, 2017 at 04:38:22PM +0100, Victor Stinner wrote: [...] > Python 3 promotes Unicode everywhere including filenames. A solution to > support filenames not decodable from the locale encoding was found: the > ``surrogateescape`` error handler (`PEP 393 >

Re: [Python-ideas] incremental hashing in __hash__

On Thu, Jan 5, 2017 at 10:58 AM Paul Moore wrote: > On 5 January 2017 at 13:28, Neil Girdhar wrote: > > The point is that the OP doesn't want to write his own hash function, but > > wants Python to provide a standard way of hashing an iterable.

Re: [Python-ideas] PEP 540: Add a new UTF-8 mode

> https://www.python.org/dev/peps/pep-0540/ I read the PEP 538, PEP 540, and issues related to switching to UTF-8. At least, I can say one thing: people have different points of view :-) To understand why people disagree, I tried to categorize the different point of views and Python

Re: [Python-ideas] incremental hashing in __hash__

On 5 January 2017 at 13:28, Neil Girdhar wrote: > The point is that the OP doesn't want to write his own hash function, but > wants Python to provide a standard way of hashing an iterable. Today, the > standard way is to convert to tuple and call hash on that. That may

[Python-ideas] PEP 540: Add a new UTF-8 mode

Hi, Nick Coghlan asked me to review his PEP 538 "Coercing the legacy C locale to C.UTF-8": https://www.python.org/dev/peps/pep-0538/ Nick wants to change the default behaviour. I'm not sure that I'm brave enough to follow this direction, so I proposed my old "-X utf8" command line idea as a new

Re: [Python-ideas] incremental hashing in __hash__

On Thu, Jan 5, 2017, at 04:00, Matt Gilson wrote: > But, I think that the problem with adding `__hash__` to > collections.abc.Iterable is that not all iterables are immutable -- And > if > they aren't immutable, then allowing them to be hashed is likely to be a > pretty bad idea... Why? This

Re: [Python-ideas] incremental hashing in __hash__

On Thu, Jan 5, 2017 at 4:00 AM Matt Gilson wrote: > But, I think that the problem with adding `__hash__` to > collections.abc.Iterable is that not all iterables are immutable -- And if > they aren't immutable, then allowing them to be hashed is likely to be a > pretty bad

Re: [Python-ideas] incremental hashing in __hash__

On 28.12.2016 04:13, j...@math.brown.edu wrote: > Suppose you have implemented an immutable Position type to represent > the state of a game played on an MxN board, where the board size can > grow quite large. > ... > > According to >

Re: [Python-ideas] incremental hashing in __hash__

But, I think that the problem with adding `__hash__` to collections.abc.Iterable is that not all iterables are immutable -- And if they aren't immutable, then allowing them to be hashed is likely to be a pretty bad idea... I'm still having a hard time being convinced that this is very much of an

Re: [Python-ideas] incremental hashing in __hash__

On 5 January 2017 at 00:31, Steven D'Aprano wrote: > This is a good point. Until now, I've been assuming that > hash.from_iterable should consider order. But frozenset shows us that > sometimes the hash should *not* consider order. > > This hints that perhaps the