Hey all,
I just wanted to clarify, that I am very excited about a few ideas I have
--- but I don't have time myself to engage in the community process to get
these changes into NumPy. However, those are real processes --- I've
been coaching a few people in those processes for the past several
If it helps anyone in their interest level. My intention would be to make
these changes to NumPy only available on Python 3 as a way to help continue
adoption of Python 3.
-Travis
--
*Travis Oliphant*
*Co-founder and CEO*
@teoliphant
512-222-5440
http://www.continuum.io
- because I won't have the
time to follow-up with any questions or comments.Even if I can't find
someone I will publish the ideas --- but that also takes time and effort
that is in short supply for me right now.
If there is someone willing to fund this work, please let me know as
spreading, and so we
welcome any and all contributions.
Thank you,
Travis Oliphant
___
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
Greg Ewing wrote:
Nick Coghlan wrote:
Maintaining a PyDict instance to map from view pointers to shapes
and strides info doesn't strike me as a "complex scheme" though.
I don't see why a given buffer provider should ever need
more than one set of shape/strides arrays at a time. It
can allocate
Antoine Pitrou wrote:
Nick Coghlan gmail.com> writes:
I don't see anything wrong with the PEP 3118 protocol.
Apart from the fact that:
- it uses something (Py_buffer) which is not a PyObject and has totally
different allocation/lifetime semantics (which makes it non-trivial to adapt to
for an
Nick Coghlan wrote:
Antoine Pitrou wrote:
In all honesty, I admit I am annoyed by all the problems with the buffer API /
memoryview object, many of which are caused by its utterly bizarre design (and
the fact that the design team went missing in action after imposing such a
bizarre and complex d
Greg Ewing wrote:
Antoine Pitrou wrote:
Why should it need two? Why couldn't the embedded Py_buffer fullfill
all the
needs of the memoryview object?
Two things here:
1) The memoryview should *not* be holding onto a Py_buffer
in between calls to its getitem and setitem methods. It
Antoine Pitrou wrote:
Nick Coghlan gmail.com> writes:
For the slicing problem in particular, memoryview is currently trying to
get away with only one Py_buffer object when it needs TWO.
Why should it need two? Why couldn't the embedded Py_buffer fullfill all the
needs of the memoryview object
Antoine Pitrou wrote:
Alexander Belopolsky gmail.com> writes:
I did not follow numpy development for the last year or more, so I
won't qualify as "the numpy folks," but my understanding is that numpy
does exactly what Nick recommended: the viewed object owns shape and
strides just as it owns th
Alexander Belopolsky wrote:
On Mon, Dec 8, 2008 at 6:25 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
..
Alexander's suggestion of going and looking at what the numpy folks have
done in this area is probably a good idea too.
Well, I'm open to others doing this, but I won't do it myself. My inte
Antoine Pitrou wrote:
Hello,
The Py_buffer struct has two pointers named `shape` and `strides`. Each points
to an array of Py_ssize_t values whose length is equal to the number of
dimensions of the buffer object. Unfortunately, the buffer protocol spec doesn't
explain how allocation of these arr
addition
to the old buffer protocol.
In addition, I've planned to back-port the improvements to the struct
module and the addition of the memoryview object (both in PEP 3118).
If you have questions, we can talk tomorrow.
Best regards,
-Travis Oliphant
Guido van Rossum wrote:
> Moving this to a new subject to keep the discussion of tasks and the
> discussion of task tracking tools separate.
>
> On Sun, Mar 16, 2008 at 9:42 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
>> I did a quick brainstorming with me, myself and I. I came up with a list
Lisandro Dalcin wrote:
> On 2/11/08, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>> My perception is that you are seeing too much of a connection between
>> the C-compiler and the PEP description of memory. Perhaps that's not
>> it, and I'm missing something e
Thomas Heller wrote:
> Travis Oliphant schrieb:
>
>>
>> The intent of the struct syntax is to handle describing memory. The
>> point is not to replicate how the C-compiler deals with statically
>> defined N-D arrays. Thus, even though the struct syntax allows
&g
Thomas Heller wrote:
> Hi Travis,
>
> The pep contains this sample:
>
> """
> Nested array
> ::
>
> struct {
> int ival;
> double data[16*4];
> }
> """i:ival:
>(16,4)d:data:
> """
> """
>
> I think it is wrong and must b
Hi all,
I think the latest patch for fixing Issue 708374 (adding offset to mmap)
should be committed to SVN.
I will do it, if nobody opposes the plan. I think it is a very
important addition and greatly increases the capability of the mmap module.
Thanks,
-Travis Oliphant
P.S. Initially
Brett Cannon wrote:
> Neal, Anthony, Thomas W., and I have a spreadsheet that was started to
> keep track of what needs to be done in what needs to be done in 2.6
> for Py3K transitioning:
> http://spreadsheets.google.com/pub?key=pCKY4oaXnT81FrGo3ShGHGg . I am
> opening the spreadsheet up to every
Carl Banks wrote:
> Travis Oliphant wrote:
>> Carl Banks wrote:
>>> Ok, I've thought quite a bit about this, and I have an idea that I
>>> think will be ok with you, and I'll be able to drop my main
>>> objection. It's not a big change, eit
Carl Banks wrote:
> Ok, I've thought quite a bit about this, and I have an idea that I
> think will be ok with you, and I'll be able to drop my main
> objection. It's not a big change, either. The key is to explicitly
> say whether the flag allows or requires. But I made a few other
> change
Greg Ewing wrote:
> Carl Banks wrote:
>
>> Py_BUF_REQUIRE_READONLY - Raise excpetion if the buffer is writable.
>
> Is there a use case for this?
Yes. The idea is used in NumPy all the time.
Suppose you want to write to an array but only have an algorithm that
works with contiguous data. Then
Greg Ewing wrote:
> Travis Oliphant wrote:
>
>> Carl Banks wrote:
>> > I'd like to see it accept a flags argument over what kind of buffer
>> > it's allowed to return. I'd rather not burden the user to check
>> all > the entri
ght
now on the extensions to the struct module until the rest is approved.
Thank you for any and all comments:
-Travis
:PEP: XXX
:Title: Revising the buffer protocol
:Version: $Revision: $
:Last-Modified: $Date: $
:Authors: Travis Oliphant <[EMAIL PROTECTED]>, Carl Banks <[EMAIL PROTECTE
Carl Banks wrote:
> Tr
> ITSM that we are using the word "view" very differently. Consider
> this example:
>
> A = zeros((100,100))
> B = A.transpose()
You are thinking of NumPy's particular use case. I'm thinking of a
generic use case. So, yes I'm using the word view in two different
cont
Greg Ewing wrote:
> But since the NumPy object has to know about the provider,
> it can simply pass the release call on to it if appropriate.
> I don't see how this case necessitates making the release call
> on a different object.
>
> I'm -1 on involving any other objects or returning object
> re
Greg Ewing wrote:
> Travis Oliphant wrote:
>
>> It is more convenient to store any slicing information (so a memory
>> view object could store an arbitrary slice of another object) as
>> offsets, lengths, and skips which can be used to adjust the memory
>> buf
Paul Moore wrote:
> On 09/04/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
>>>I have skimmed (briefly, I'll admit!) the pre-PEP, but I've found it
>>>extremely difficult to find a simple example of the basic (in my view)
>>>use case of an un
Carl Banks wrote:
>
> The thing that bothers me about this whole flags setup is that
> different flags can do opposite things.
>
> Some of the flags RESTRICT the kind of buffers that can be
> exported (Py_BUF_WRITABLE); other flags EXPAND the kind of buffers that
> can be exported (Py_BUF_INDIRECT
Lisandro Dalcin wrote:
> On 4/9/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
> Travis, all this is far better and simpler than previous approaches...
> Just a few comments
Thanks for your wonderful suggestions. I've incorporated many of them.
>
> 1) I assume tha
Neil Hodgson wrote:
> Travis Oliphant:
>
>> PEP: 3118
>> ...
>
> I'd like to see the PEP include discussion of what to do when an
> incompatible request is received while locked. Should there be a
> standard "Can't do that: my buffer has been got&quo
Greg Ewing wrote:
> From PEP 3118:
>
> A memory-view object is an extended buffer object that
> should replace the buffer object in Python 3K.
>
> typedef struct {
> PyObject_HEAD
> PyObject *base;
> struct bufferinfo view;
> int itemsize;
> int flags;
> } PyMemoryViewOb
Carl Banks wrote:
>
>
> Travis Oliphant wrote:
> > Py_BUF_READONLY
> >The returned buffer must be readonly and the underlying object
> should make
> >its memory readonly if that is possible.
>
> I don't like the "if possible" thing. I
3118
Title: Revising the buffer protocol
Version: $Revision$
Last-Modified: $Date$
Authors: Travis Oliphant <[EMAIL PROTECTED]>, Carl Banks <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 28-Aug-2006
Python-Version: 3000
Abstract
Paul Moore wrote:
> Hi,
> I'll admit right off that I haven't followed all of the extended
> buffer protocol discussions - I have no real need for anything much
> beyond the existing "here's a blob of memory" level of functionality.
>
> I have skimmed (briefly, I'll admit!) the pre-PEP, but I've f
Carl Banks wrote:
> Only one concern:
>
> > typedef int (*getbufferproc)(PyObject *obj, struct bufferinfo
> *view)
>
>
> I'd like to see it accept a flags argument over what kind of buffer
> it's allowed to return. I'd rather not burden the user to check all
> the entries in bufferinfo to m
Carl Banks wrote:
> Travis E. Oliphant wrote:
>> I think we are getting closer. What do you think about Greg's idea
>> of basically making the provider the bufferinfo structure and having
>> the exporter handle copying memory over for shape and strides if it
>> wants to be able to change those
Lisandro Dalcin wrote:
> On 3/26/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>> Here is my updated PEP which incorporates several parts of the
>> discussions we have been having.
>
> Travis, it looks really good, below my comments
I hope you don't mind me reply
Travis Oliphant wrote:
> Hi Carl and Greg,
>
> Here is my updated PEP which incorporates several parts of the
> discussions we have been having.
>
And here is the actual link:
http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/doc/pep_buffer.tx
Hi Carl and Greg,
Here is my updated PEP which incorporates several parts of the
discussions we have been having.
-Travis
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://ma
Carl Banks wrote:
> We're done. Return pointer.
Thank you for this detailed example. I will have to parse it in more
depth but I think I can see what you are suggesting.
>
> First, I'm not sure why getbuffer needs to return a view object.
The view object in your case would just be the Image
Greg Ewing wrote:
> Travis Oliphant wrote:
>
>
>>I'm talking about arrays of pointers to other arrays:
>>
>>i.e. if somebody defined in C
>>
>>float B[10][20]
>>
>>then B would B an array of pointers to arrays of floats.
>
>
> N
Greg Ewing wrote:
> Travis Oliphant wrote:
>
>
>>The question is should we eliminate the possibility of sharing memory
>>for objects that store data basically as "arrays" of arrays (i.e. true
>>C-style arrays).
>
>
> Can you clarify what you mea
Attached is the PEP.
:PEP: XXX
:Title: Revising the buffer protocol
:Version: $Revision: $
:Last-Modified: $Date: $
:Author: Travis Oliphant <[EMAIL PROTECTED]>
:Status: Draft
:Type: Standards Track
:Content-Type: text/x-rst
:Created: 28-Aug-2006
:Python-Version: 3000
Abstract
memory, or an iterator object that iterates through every element of any
object that exposes the buffer protocol.
Thanks for any feedback,
-Travis Oliphant
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
Martin v. Löwis wrote:
>Travis Oliphant schrieb:
>
>
>>>>r_field = PyDict_GetItemString(dtype,'r');
>>>>
>>>>
>>>>
>>Actually it should read PyDict_GetItemString(dtype->fields).The
>>r_field is a
>
> Perhaps the most relevant thing to pull from this conversation is back
> to what Martin has asked about before: "flexible array members". A TCP
> packet has no defined length (there isn't even a header field in the
> packet for this, so in fairness we can talk about IP packets which
> do).
T
>
> IIUC, so far the 'data-object' carries information about the structure
> of the data it describes.
>
> Couldn't it go a step further and have also some functionality?
> Converting the data into a Python object and back?
>
Yes, I had considered it to do that. That's why the setfunc and get
Martin v. Löwis wrote:
> Travis E. Oliphant schrieb:
>
>>>2. Should primitive type codes be characters or integers (from an enum) at
>>>C level?
>>>- I prefer integers
>>
>>>3. Should size be expressed in bits or bytes?
>>>- I prefer bits
>>>
>>
>>So, you want an integer enum for the "kind
Paul Moore wrote:
>
>
> Enough of the abstract. As a concrete example, suppose I have a (byte)
> string in my program containing some binary data - an ID3 header, or a
> TCP packet, or whatever. It doesn't really matter. Does your proposal
> offer anything to me in how I might manipulate that dat
Alexander Belopolsky wrote:
> Travis Oliphant ieee.org> writes:
>
>
>>>>b = buffer(array('d', [1,2,3]))
>
>
> there is not much that I can do with b. For example, if I want to pass it to
> numpy, I will have to provide the type and shape inform
Fredrik Lundh wrote:
> Chris Barker wrote:
>
>
>>While /F suggested we get off the PIL bandwagon
>
>
> I suggest we drop the obsession with pointers to memory areas that are
> supposed to have a specific format; modern data access API:s don't work
> that way for good reasons, so I don't see w
Martin v. Löwis wrote:
> Travis E. Oliphant schrieb:
>
>>2) complex-valued types (you might argue that it's just a 2-array of
>>floats, but you could say the same thing about int as an array of
>>bytes). The point is how do people interpret the data. Complex-valued
>>data-types are very commo
Fredrik Lundh wrote:
> Chris Barker wrote:
>
>
>>While /F suggested we get off the PIL bandwagon
>
>
> I suggest we drop the obsession with pointers to memory areas that are
> supposed to have a specific format; modern data access API:s don't work
> that way for good reasons, so I don't see w
Martin v. Löwis wrote:
> Travis E. Oliphant schrieb:
>
>>> Or, if it does have uses independent of the buffer extension: what
>>> are those uses?
>>>
>> So that NumPy and ctypes and audio libraries and video libraries and
>> database libraries and image-file format libraries can communic
Jim Jewett wrote:
> I'm still not sure exactly what is missing from ctypes. To make this
> concrete:
I think the only thing missing from ctypes "expressiveness" as far as I
can tell in terms of what you "can" do is the byte-order representation.
What is missing is ease-of use for producers and
Martin v. Löwis wrote:
> Travis E. Oliphant schrieb:
>
>>Several extensions to Python utilize the buffer protocol to share
>>the location of a data-buffer that is really an N-dimensional
>>array. However, there is no standard way to exchange the
>>additional N-dimensional array in
Paul Moore wrote:
> On 10/31/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
>>Martin v. Löwis wrote:
>>
>>>[...] because I still don't quite understand what the PEP
>>>wants to achieve.
>>>
>>
>>Are you saying you still don&#x
Martin v. Löwis wrote:
> Stephan Tolksdorf schrieb:
>
>>While Travis' proposal encompasses the data format functionality within
>>the struct module and overlaps with what ctypes has to offer, it does
>>not aim to replace ctypes.
>
>
> This discussion could have been a lot shorter if he had sai
Thomas Heller wrote:
>
> (I tried to read the whole thread again, but it is too large already.)
>
> There is a (badly named, probably) api to access information
> about ctypes types and instances of this type. The functions are
> PyObject_stgdict(obj) and PyType_stgdict(type). Both return a
> '
Martin v. Löwis wrote:
> Travis E. Oliphant schrieb:
>
>>But, there are distinct disadvantages to this approach compared to what
>>I'm trying to allow. Martin claims that the ctypes approach is
>>*basically* equivalent but this is just not true.
>
>
> I may claim that, but primarily, my goal
Martin v. Löwis wrote:
> Travis Oliphant schrieb:
>
>>The big difference, however, is that by going this route you are forced
>>to use the "type object" as your data-format "instance".
>
>
> Since everything is an object (an "instance) i
Nick Coghlan wrote:
> Travis E. Oliphant wrote:
>
>>However, the existence of an alternative strategy using a single Python
>>type and multiple instances of that type to describe binary data (which
>>is the NumPy approach and essentially the array module approach) means
>>that we can't just a-p
Martin v. Löwis wrote:
> Travis Oliphant schrieb:
>
>>So, the big difference is that I think data-formats should be
>>*instances* of a single type.
>
>
> This is nearly the case for ctypes as well. All layout descriptions
> are instances of the type type. Near
Greg Ewing wrote:
> Travis Oliphant wrote:
>
>
>>Part of the problem is that ctypes uses a lot of different Python types
>>(that's what I mean by "multi-object" to accomplish it's goal). What
>>I'm looking for is a single Python type t
Armin Rigo wrote:
> Hi Travis,
>
> On Fri, Oct 27, 2006 at 02:05:31PM -0600, Travis E. Oliphant wrote:
>
>>This PEP proposes adapting the data-type objects from NumPy for
>>inclusion in standard Python, to provide a consistent and standard
>>way to discuss the format of binary data.
Martin v. Löwis wrote:
> Robert Kern schrieb:
>
>>>As I unification mechanism, I think it is insufficient. I doubt it
>>>can express all the concepts that ctypes supports.
>>
>>What do you think is missing that can't be added?
>
>
> I can factually only report what is missing. Whether it can be
Greg Ewing wrote:
> Travis E. Oliphant wrote:
>
>
>>Greg Ewing wrote:
>
>
>>>What exactly does "bit" mean in that context?
>>
>>Do you mean "big" ?
>
>
> No, you've got a data type there called "bit",
> which seems to imply a size, in contradiction
> to the size-independent nature of the o
Jim Jewett wrote:
> Travis E. Oliphant wrote:
>
>
>>Two packages need to share a chunk of memory (the package authors do not
>>know each other and only have and Python as a common reference). They
>>both want to describe that the memory they are sharing has some
>>underlying binary structure.
>
Martin v. Löwis wrote:
> Josiah Carlson schrieb:
>
>>One could also toss wxPython, VTK, or any one of the other GUI libraries
>>into the mix for visualizing those images, of which wxPython just
>>acquired no-copy display of PIL images, and being able to manipulate
>>them with numpy (of which some
Guido van Rossum wrote:
>
> What do you think (10**10).__index__() should return (when called from
> Python)?
>
I'm with Guido on this point. I think (10**10).__index__() should
return the full long integer when called from within Python.
-Travis
__
Nick Coghlan wrote:
> Nick Coghlan wrote:
>> Armin Rigo wrote:
>>> Hi,
>>>
>>> There is an oversight in the design of __index__() that only just
>>> surfaced :-( It is responsible for the following behavior, on a 32-bit
>>> machine with >= 2GB of RAM:
>>>
>>> >>> s = 'x' * (2**100) # wor
Nick Coghlan wrote:
>
>
> One possibility would be to invert the sense of that flag and call it
> "typeerror", which probably more accurately reflects what it's intended for -
> it's a way of telling the function "if this object does not have the correct
> type, tell me by setting this flag in
Nick Coghlan wrote:
> David Hopwood wrote:
>> Armin Rigo wrote:
>>> Hi,
>>>
>>> There is an oversight in the design of __index__() that only just
>>> surfaced :-( It is responsible for the following behavior, on a 32-bit
>>> machine with >= 2GB of RAM:
>>>
>>> >>> s = 'x' * (2**100) # wo
class of
NumPy) will be proposed for inclusion in Python. When that happens
some kind of data-type object (a super class of the NumPy dtype object)
will be needed as well.
I think some cross-talk between all of us different users of the notion
of what we in the NumPy community call a data
Steven Bethard wrote:
> I know 2.5's not out yet, but since I now have a PEP number, I'm going
> to go ahead and post this for discussion. Currently, the target
> version is Python 2.6. You can also see the PEP at:
> http://www.python.org/dev/peps/pep-0359/
>
> Thanks in advance for the feed
If you have Numeric or numpy installed try this:
#import Numeric as N
import numpy as N
a = range(10)
b = N.arange(10)
a.__iadd__(b)
print a
Result:
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
Contrast the returned output with
import numpy as N
a = range(10)
b = N.arange
Edward C. Jones wrote:
> "Travis E. Oliphant" <[EMAIL PROTECTED]> wrote:
>
> > It is very important for many people to get access to memory with some
> > description of how that memory should be interpreted as an array.
> > Several Python packages could benefit if Python had some notion of an
>
Thomas Wouters wrote:
> On Fri, Feb 17, 2006 at 04:40:08PM -0700, Travis Oliphant wrote:
>
>
>>What is PY_SSIZE_T_MAX supposed to be? The definition in pyport.h
>>doesn't compile.
>
Maybe I have the wrong version of code. In my pyport.h (checked out
fro
Martin v. Löwis wrote:
> Just in case you haven't noticed, I just merged
> the ssize_t branch (PEP 353).
>
> If you have any corrections to the code to make which
> you would consider bug fixes, just go ahead.
>
> If you are uncertain how specific problems should be resolved,
> feel free to ask.
Thomas Wouters wrote:
> On Fri, Feb 17, 2006 at 05:29:32PM +0100, Armin Rigo wrote:
>
>>> Where obj must be either an int or a long or another object that has
>>> the
>>> __index__ special method (but not self).
>
>
>>The "anything but not self" rule is not consistent with any other
Eric Nieuwland wrote:
> Travis Oliphant wrote:
>
>> PEP: ###
>> Title: Allowing any object to be used for slicing
>> [...]
>> Rationale
>>
>>Currently integers and long integers play a special role in slice
>>notation in that they are th
ified: $Date: 2006/02/09 $
Author: Travis Oliphant
Status: Draft
Type: Standards Track
Created: 09-Feb-2006
Python-Version: 2.5
Abstract
This PEP proposes adding an sq_index slot in PySequenceMethods and
an __index__ special method so that arbitrary objects can be used
in slice s
Thank you, Martin and Stephen, for the suggestions and comments.
For your information:
We decided that all NumPy arrays of unicode strings will use UCS4 for
internal representation. When an element of the array is selected, a
unicodescalar (which inherits directly from the unicode builtin type
Martin v. Löwis wrote:
> Travis Oliphant wrote:
>
>> As verified by removing usage of the Python PyObject_MALLOC function,
>> it was the Python memory manager that was performing poorly. Even
>> though the array-scalar objects were deleted, the memory manager
>>
Martin v. Löwis wrote:
> Travis Oliphant wrote:
>
>> So, I now believe that his code (plus the array scalar extension
>> type) was actually exposing a real bug in the memory manager itself.
>> In theory, the Python memory manager should have been able to re-use
>
>>
>> Bingo. Yes, definitely allocating new _types_ (an awful lot of
>> them...)
>> --- that's what the "array scalars" are: new types created in C.
>
>
> Do you really mean that someArray[1] will create a new type to represent
> the second element of someArray? I would guess that you create an
Jim Jewett wrote:
>Do you have the code that caused problems?
>
>
Yes. I was able to reproduce his trouble and was trying to debug it.
>The things I would check first are
>
>(1) Is he allocating (peak usage) a type (such as integers) that
>never gets returned to the free pool, in case you nee
Josiah Carlson wrote:
>Robert Kern <[EMAIL PROTECTED]> wrote:
>
>
>>[1] There *is* an array type for general PyObjects in scipy_core, but
>>that's not being used in the code that blows up and has nothing to do
>>with the problem Travis is talking about.
>>
>>
>
>I seemed to have misunderstoo
[EMAIL PROTECTED] wrote:
>Travis> More to the point, however, these scalar objects were allocated
>Travis> using the standard PyObject_New and PyObject_Del functions which
>Travis> of course use the Python memory manager. One user ported his
>Travis> (long-running) code to the new
other people as well. Also, is there a
recommended way for dealing with this problem other than using system
malloc and system free (or I suppose writing your own specialized memory
manager).
Thanks for any feedback,
-Travis Oliphant
___
Python-Dev ma
Guido van Rossum wrote:
>On 10/1/05, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
>
>>The new ndarray object of scipy core (successor to Numeric Python) is a
>>C extension type that has a getitem defined in both the as_mapping and
>>the as_sequence structure
.__getitem__ wrapper method.
Why does this wrapper call the sequence getitem instead of the mapping
getitem method?
Is there anyway to get at a mapping-style __getitem__ method from Python?
This looks like a bug to me (which is why I'm posting here...)
Thanks for any help or insight.
-T
eric3 now called
scipy.base) has a collection of C-types that represent each
C-datatype. They are (arguably) useful in the context of eliminating a
few problems in data-type coercion in scientific computing.
These types are created in C and u
Greg Ewing wrote:
Travis Oliphant wrote:
I'm proposing to pickle the buffer object so that it unpickles as a
string.
Wouldn't this mean you're only solving half the problem?
Unpickling a Numeric array this way would still use an
intermediate string.
Well, actually, unpickling in
buffer object would need to be reworked into something more
along the lines of the previously-proposed bytes object before a
separate bytecode for pickleable mutable-bytes is accepted, however.
-Travis Oliphant
___
Python-Dev mailing list
P
I'm posting to this list to again generate open discussion on the
problem in current Python that an int is used in both the Python
sequence protocol and the Python buffer protocol.
The problem is that a C-int is typically only 4 bytes long while there
are many applications (mmap for example),
tor object. (Perhaps a PythonMethod descriptor object to
complement the Method Descriptor).
Any hints will be helpful.
-Travis Oliphant
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
Guido van Rossum wrote:
Would it be possible to change
_PyEval_SliceIndex in ceval.c
so that rather than throwing an error if the indexing object is not an
integer, the code first checks to see if the object has a
tp_as_number->nb_int method and calls it instead.
I don't think this is the rig
eption.
If this is acceptable, it is an easy patch.
Thanks,
-Travis Oliphant
___
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%
1 - 100 of 107 matches
Mail list logo
