A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2000-December/010910.html below:

[Python-Dev] What's up with PEP 209: Adding Multidimensional Arrays

[Python-Dev] What's up with PEP 209: Adding Multidimensional ArraysPaul Barrett Barrett@stsci.edu
Fri, 8 Dec 2000 16:22:39 -0500 (EST)
Guido van Rossum writes:
 > > What is the status of PEP 209?  I see David Ascher is the champion of
 > > this PEP, but nothing has been written up.  Is the intention of this
 > > PEP to make the current Numeric a built-in feature of Python or to
 > > re-implement and replace the current Numeric module?
 > 
 > David has already explained why his name is on it -- basically,
 > David's name is on several PEPs but he doesn't currently have any time
 > to work on these, so other volunteers are most welcome to join.
 > 
 > It is my understanding that the current Numeric is sufficiently messy
 > in implementation and controversial in semantics that it would not be
 > a good basis to start from.

That is our (Rick, Perry, and I) belief also.

 > However, I do think that a basic multi-dimensional array object would
 > be a welcome addition to core Python.

That's re-assuring.

 > Indeed.  I think it's best to leave the buffer object out of your
 > implementation plans.  There are several problems with it, and one of
 > the backburner projects is to redesign it to be much more to the point
 > (providing less, not more functionality).

I agree and have already made the decision to leave it out.

 > > My opinion on this is that a new _fundamental_ built-in type should be
 > > created for memory allocation with features and an interface similar
 > > to the _mmap_ object.  I'll call this a _malloc_ object.  This would
 > > allow Numeric 2 to use either object interchangeably depending on the
 > > circumstance.  The _string_ type could also benefit from this new
 > > object by using a read-only version of it.  Since its an object, it's
 > > memory area should be safe from inadvertent deletion.
 > 
 > Interesting.  I'm actually not sufficiently familiar with mmap to
 > comment.  But would the existing array module's array object be at all
 > useful?  You can get to the raw bytes in C (using the C buffer API,
 > which is not deprecated) and it is extensible.

I tried using this but had problems.  I'll look into it again.

 > > Because of these and other new features in Numeric 2, I have a keen
 > > interest in the status of PEPs 207, 208, 211, 225, and 228; and also
 > > in the proposed buffer object.  
 > 
 > Here are some quick comments on the mentioned PEPs.

I've got these PEPs on my desk and will comment on them when I can.

 > > I'm willing to implement this new _malloc_ object if members of the
 > > python-dev list are in agreement.  Actually I see no alternative,
 > > given the current design of Numeric 2, since the Array class will
 > > initially be written completely in Python and will need a mutable
 > > memory buffer, while the _string_ type is meant to be a read-only
 > > object.
 > 
 > Would you be willing to take over authorship of PEP 209?  David Ascher
 > and the Numeric Python community will thank you.

Yes, I'd gladly wield vast and inconsiderate power over unsuspecting
pythoneers. ;-)

 -- Paul





RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4