> You can't expect the memoryview() to magically know what the underlying
> hash function is.
Hashable objects implementing the buffer interface could be required to
make their hash implementation consistent with bytes hashing. IMO, that
wouldn't be asking too much.
There is already the issue th
Antoine Pitrou wrote:
> Stefan Krah wrote:
> > I think they necessarily have to use the same hash, since:
> >
> > exporter = m1 ==> hash(exporter) = hash(m1)
> > m1 = m2 ==> hash(m1) = hash(m2)
> >
> > Am I missing something?
>
> The hash must simply be calculated using the same algorithm (whi
Stefan Krah, 13.11.2011 13:05:
Nick Coghlan wrote:
With slices or the new casts (See: http://bugs.python.org/issue5231,
implemented in http://hg.python.org/features/pep-3118#memoryview ),
it is possible to have different hashes for equal objects:
Note that Antoine isn't suggesting that the und
On Sun, 13 Nov 2011 13:05:24 +0100
Stefan Krah wrote:
> Nick Coghlan wrote:
> > > With slices or the new casts (See: http://bugs.python.org/issue5231,
> > > implemented in http://hg.python.org/features/pep-3118#memoryview ),
> > > it is possible to have different hashes for equal objects:
> >
>
Nick Coghlan wrote:
> > With slices or the new casts (See: http://bugs.python.org/issue5231,
> > implemented in http://hg.python.org/features/pep-3118#memoryview ),
> > it is possible to have different hashes for equal objects:
>
> Note that Antoine isn't suggesting that the underlying hash be *u
Antoine Pitrou wrote:
> > > 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)
> >
> > With slices or the new casts (See: http://bugs.python.org/issue5231,
> > imp
On Sun, Nov 13, 2011 at 8:49 PM, Antoine Pitrou wrote:
> I don't understand this feature. How do you represent a reversed buffer
> using the buffer API, and how do you ensure that consumers (especially
> those written in C) see the buffer reversed?
The values in the strides array are signed, so p
On Sun, Nov 13, 2011 at 8:39 PM, Stefan Krah wrote:
> Antoine Pitrou wrote:
>> 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
On Sun, 13 Nov 2011 11:39:46 +0100
Stefan Krah wrote:
> Antoine Pitrou wrote:
> > 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
>
Antoine Pitrou wrote:
> 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)
Wit
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.
>
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 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
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
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
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
16 matches
Mail list logo
