Re: [Python-Dev] Hashable memoryviews

2011-11-13 Thread Stefan Krah
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

Re: [Python-Dev] Hashable memoryviews

2011-11-13 Thread Antoine Pitrou
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 >

Re: [Python-Dev] Hashable memoryviews

2011-11-13 Thread Nick Coghlan
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

Re: [Python-Dev] Hashable memoryviews

2011-11-13 Thread Nick Coghlan
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

Re: [Python-Dev] Hashable memoryviews

2011-11-13 Thread Stefan Krah
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

Re: [Python-Dev] Hashable memoryviews

2011-11-13 Thread Stefan Krah
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

Re: [Python-Dev] Hashable memoryviews

2011-11-13 Thread Antoine Pitrou
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: > > >

Re: [Python-Dev] Hashable memoryviews

2011-11-13 Thread Stefan Behnel
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

Re: [Python-Dev] Hashable memoryviews

2011-11-13 Thread Stefan Krah
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

Re: [Python-Dev] order of Misc/ACKS

2011-11-13 Thread Stephen J. Turnbull
Xavier Morel writes: > On 2011-11-12, at 10:24 , Georg Brandl wrote: > > Am 12.11.2011 08:03, schrieb Stephen J. Turnbull: > >> 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 > > worryi

[Python-Dev] _PyImport_FindExtensionObject() does not set _Py_PackageContext

2011-11-13 Thread Stefan Behnel
Hi, I noticed that _PyImport_FindExtensionObject() in Python/import.c does not set _Py_PackageContext when it calls the module init function for module reinitialisation. However, PyModule_Create2() still uses that variable to figure out the fully qualified module name. Was this intentionally l

[Python-Dev] how to find the file path to an extension module at init time?

2011-11-13 Thread Stefan Behnel
Hi, in Python modules, the "__file__" attribute is provided by the runtime before executing the module body. For extension modules, it is set only after executing the init function. I wonder if there's any way to figure out where an extension module is currently being loaded from. The _PyImpo

Re: [Python-Dev] Hashable memoryviews

2011-11-13 Thread Martin v. Löwis
> 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

Re: [Python-Dev] how to find the file path to an extension module at init time?

2011-11-13 Thread Martin v. Löwis
> I'm asking specifically because I'd like to properly implement __file__ > in Cython modules at module init time. Why do you need to implement __file__? Python will set it eventually to its correct value, no? > Another problem is that package local imports from __init__.py no longer > work when

Re: [Python-Dev] peps: And now for something completely different.

2011-11-13 Thread Antoine Pitrou
On Sun, 13 Nov 2011 22:33:28 +0100 barry.warsaw wrote: > > +And Now For Something Completely Different > +== So, is the release manager a man with two noses? > +Strings and bytes > +- > + > +Python 2's basic original string type are calle

Re: [Python-Dev] [Python-checkins] cpython (2.7): Normalize the keyword arguments documentation notation in re.rst. Closes issue

2011-11-13 Thread Terry Reedy
On 11/13/2011 5:52 PM, eli.bendersky wrote: http://hg.python.org/cpython/rev/87ecfd5cd5d1 changeset: 73541:87ecfd5cd5d1 branch: 2.7 parent: 73529:c3b063c82ae5 user:Eli Bendersky date:Mon Nov 14 01:02:20 2011 +0200 summary: Normalize the keyword arguments documentati

Re: [Python-Dev] [Python-checkins] cpython (2.7): Normalize the keyword arguments documentation notation in re.rst. Closes issue

2011-11-13 Thread Eli Bendersky
>> http://hg.python.org/cpython/rev/87ecfd5cd5d1 >> changeset:   73541:87ecfd5cd5d1 >> branch:      2.7 >> parent:      73529:c3b063c82ae5 >> user:        Eli Bendersky >> date:        Mon Nov 14 01:02:20 2011 +0200 >> summary: >>   Normalize the keyword arguments documentation notation in re.rst.