Christian Heimes wrote:
> Guido van Rossum wrote:
>
>> I do think that another (final) 3.0 alpha before PyCon would also be a
>> good idea. This way we can gel the release some more. For 2.6 I think
>> we'll need more alpha releases after PyCon; I doubt the backporting
>> from 3.0 (which has onl
Jim Jewett wrote:
> Reading this message without the entire PEP in front of me showed some
> confusing usage. (Details below) Most (but not all) I could resolve
> from the PEP itself, but they could be clarified with different
> constant names.
>
I'm going to adapt some suggestions made by you
I'd like to ask for access to Python SVN so that I can keep the PEP 3118
up to date as well as to eventually make the changes needed for
implementing the extended buffer protocol.
I have quite a bit of experience with the Python C-API and understand
many parts of the code base fairly well (thou
The latest update is here. Carl and Greg, can I add your names to the
PEP author list?
I think we are very close. I'd like to start working on the
implmentation. The modifications to the struct module is probably where
I'll start.
I really like the possibilities this will open up for shari
Carl Banks wrote:
> Travis Oliphant wrote:
>> 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
Greg Ewing wrote:
> Here's another idea, to allow multiple views of the same
> buffer with different shape/stride info to coexist, but
> without extra provider objects or refcount weirdness.
> Also it avoids using calls with a brazillion arguments.
>
>struct bufferinfo {
> void **buf;
>
Alexander Belopolsky wrote:
> Travis Oliphant ieee.org> writes:
>> Don't lump those ideas together. Shapes and strides are necessary for
>> N-dimensional array's (it's essentially what *defines* the N-dimensional
>> array). I really don't want to sacrifice those in the extended buffer
>> pro
Jim Jewett wrote:
> I'm still not sure exactly what is missing from ctypes. To make this
> concrete:
I was too hasty. There are some things actually missing from ctypes:
1) long double (this is not the same across platforms, but it is a
data-type).
2) complex-valued types (you might argue tha
Martin v. Löwis wrote:
> Travis E. Oliphant schrieb:
>> What if we look at this from the angle of trying to communicate
>> data-formats between different libraries (not change the way anybody
>> internally deals with data-formats).
>
> ISTM that this is not the right
Travis E. Oliphant wrote:
> Thanks for all the comments that have been given on the data-type
> (data-format) PEP. I'd like opinions on an idea for revising the PEP I
> have.
>
> 1) We could define a special string-syntax (or list syntax) that covers
> every s
Thanks for all the comments that have been given on the data-type
(data-format) PEP. I'd like opinions on an idea for revising the PEP I
have.
What if we look at this from the angle of trying to communicate
data-formats between different libraries (not change the way anybody
internally deals
Fredrik Lundh wrote:
> Terry Reedy wrote:
>
>> I believe that at present PyGame can only work with external images that it
>> is programmed to know how to import. My guess is that if image source
>> program X (such as PIL) described its data layout in a way that NumPy could
>> read and act on,
Michael Chermside wrote:
> In this email I'm responding to a series of emails from Travis
> pretty much in the order I read them:
>
>>
>> In the mean-time, how are other packages supposed to communicate
>> binary information about data with each other?
>
> Here we disagree.
>
> I haven't used
M.-A. Lemburg wrote:
> Travis E. Oliphant wrote:
>
> I understand and that's why I'm asking why you made the range
> explicit in the definition.
>
In the case of NumPy it was so that String and Unicode arrays would both
look like multi-length string "character&quo
Attached is my PEP for extending the buffer protocol to allow array data
to be shared.
PEP:
Title: Extending the buffer protocol to include the array interface
Version: $Revision: $
Last-Modified: $Date: $
Author: Travis Oliphant <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Creat
Greg Ewing wrote:
> Travis Oliphant wrote:
>
>> The 'bit' type re-intprets the size information to be in units of "bits"
>> and so implies a "bit-field" instead of another data-format.
>
> Hmmm, okay, but now you've got another orthogonality
> problem, because you can't distinguish between e.g.
Travis Oliphant wrote:
> 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 that can be passed around an
Martin v. Löwis wrote:
> Travis E. Oliphant schrieb:
>> How to handle unicode data-formats could definitely be improved.
>
> As before, I'm doubtful what the actual needs are. For example, is
> it desired to support generation of ID3v2 tags with such a data
> format?
Martin v. Löwis wrote:
> Travis E. Oliphant schrieb:
>> What is needed is a definitive way to describe data and then have
>>
>> array
>> struct
>> ctypes
>>
>> all be compatible with that same method.That's why I'm proposing the
&g
Greg Ewing wrote:
> Travis E. Oliphant wrote:
>
>> How to handle unicode data-formats could definitely be improved.
>> Suggestions are welcome.
>
> 'U4*10' string of 10 4-byte Unicode chars
>
I like that. Thanks.
-Travis
_
Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> Greg Ewing wrote:
>
>>> Also, what if I want to refer to fields by name
>>> but don't want to have to work out all the offsets
>
>> Use the list definition form. With the changes I've
>> suggested above, you wouldn't even have to name the fields you
Greg Ewing wrote:
> Travis E. Oliphant wrote:
>
>> The 'kind' does not specify how "big" the data-type (data-format) is.
>
> What exactly does "bit" mean in that context?
Do you mean "big" ? It's how many bytes the kind is usi
Greg Ewing wrote:
> Nick Coghlan wrote:
>> I'd say the answer to where we put it will be dependent on what happens to
>> the
>> idea of adding a NumArray style fixed dimension array type to the standard
>> library. If that gets exposed through the array module as array.dimarray,
>> then
>> it
Martin v. Löwis wrote:
> Travis E. Oliphant schrieb:
>> In this case, the 'kind' does not specify how large the data-type is.
>> You can have 'u1', 'u2', 'u4', etc.
>>
>> The same is true with Unicode. You can have 10-character
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 discus
M.-A. Lemburg wrote:
> Travis E. Oliphant wrote:
>> M.-A. Lemburg wrote:
>>> Travis E. Oliphant wrote:
>>>>
>>>>
>>>> PEP:
>>>> Title: Adding data-type obj
M.-A. Lemburg wrote:
> Travis E. Oliphant wrote:
>>
>>
>>
>> PEP:
>> Title: Adding data-type objects to the standard library
>> Attributes
>>
>> kind -- returns
Greg Ewing wrote:
> Travis E. Oliphant wrote:
>> PEP:
>> Title: Adding data-type objects to the standard library
>
> Not sure about having 3 different ways to specify
> the structure -- it smacks of Too Many Ways To Do
> It to me.
You might be right, but they all hav
Martin v. Löwis wrote:
> Travis E. Oliphant schrieb:
>> The datatype is an object that specifies how a certain block of
>> memory should be interpreted as a basic data-type.
>>
>> >>> datatype(float)
>> datatype('float64'
PEP:
Title: Adding data-type objects to the standard library
Version: $Revision: $
Last-Modified: $Date: $
Author: Travis Oliphant <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Created: 05-Sep-2006
Python-Version: 2.6
Abstract
This PEP proposes adapting the data-type objects fro
Travis E. Oliphant wrote:
>
> The idea is that the __index__() method should return an exact int or
> exact long or this call will raise an error. The restriction is present
> to remove the possibility of infinite recursion (though I'm not sure
> where that would occur
Tim Peters wrote:
> [Travis E. Oliphant]
>> Right now throughout the Python code it is assumed that
>> sizeof(Py_ssize_t) <= sizeof(long).
>
> If you find any code like that, it's a bug. Win64 is a platform where
> it's false.
Sorry for my confusion. I
Neal Norwitz wrote:
> I checked in this fix for the __index__ clipping issue that's been
> discussed. This patch is an improvement, but still needs some work.
> Please pull out any parts you have an issue with and suggest a patch
> to address your concern.
>
For me the only remaining concern is
Neal Norwitz wrote:
> I checked in this fix for the __index__ clipping issue that's been
> discussed. This patch is an improvement, but still needs some work.
>
> +/* Return a Python Int or Long from the object item
> + Raise TypeError if the result is not an int-or-long
> + or if the object
Travis E. Oliphant wrote:
> Here is my C-API proposal
>
> 1) PyIndex_Check(obj)
>
>Similar to PyIter_Check(obj) as it just checks for whether or not the
> object can call nb_index. Actually implemented as a macro.
>
> 2) PyObject* PyNumber_Index(obj)
>
&
Here is my C-API proposal
1) PyIndex_Check(obj)
Similar to PyIter_Check(obj) as it just checks for whether or not the
object can call nb_index. Actually implemented as a macro.
2) PyObject* PyNumber_Index(obj)
Simple interface around nb_index that calls it if possible and returns
Ty
Guido van Rossum wrote:
> Thanks for your understanding.
>
> Anyway, Nick's patch differs in at least one significant way from my
> proposal -- (10**10).__index__() returns sys.maxint in his patch,
> while I want it to return 100L. So this is still an open
> issue.
>
I've reviewed Nick's
Guido van Rossum wrote:
> On 8/10/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
It seems like Nick's recent patches solved the problems that were
identified.
>>> Nick, can you summarize how your patches differ from my proposal?
>> nb_index and __index__ are essent
Guido van Rossum wrote:
> Here's another issue where Neal thought it would be useful if I
> weighed in. I'm not quite sure of the current status, but perhaps the
> following would work?
>
> - Called from Python, (10**10).__index__() should return 100L,
> not raise an exception or return sy
I'm hoping somebody here can help me with an error I'm getting in Python
2.3.4 but not in Python 2.4.2 when I use PyGILState_Ensure in NumPy on
Linux.
Perhaps somebody can point out what I'm doing wrong because while I've
tried to understand the threading API it can be a bit confusing and
m
Travis E. Oliphant wrote:
> I'm curious about the difference between
>
> float_subtype_new in floatobject.c
> complex_subtype_from_c_complex in complexobject.c
>
> The former uses type->tp_alloc(type, 0) to create memory for the object
> while the latter uses Py
Guido van Rossum wrote:
I wouldn't be surprised if this is a genuine bug; the complex type
doesn't get a lot of love from core developers.
Could you come up with a proposed fix, and a unit test showing that it
works (and that the old version doesn't)? (Maybe a good unit test
would require writin
I'm curious about the difference between
float_subtype_new in floatobject.c
complex_subtype_from_c_complex in complexobject.c
The former uses type->tp_alloc(type, 0) to create memory for the object
while the latter uses PyType_GenericAlloc(type, 0) to create memory for
the sub-type (thereby by-p
I'm curious about the difference between
float_subtype_new in floatobject.c
complex_subtype_from_c_complex in complexobject.c
The former uses type->tp_alloc(type, 0) to create memory for the object
while the latter uses PyType_GenericAlloc(type, 0) to create memory for
the sub-type (thereby b
Greg Ewing wrote:
> Travis Oliphant wrote:
>
>> For what it's worth, NumPy also defines a data-type object which it
>> uses to describe the fundamental data-type of an array. In the context
>> of this thread it is also yet another way to describe a binary-packed
>> structure in Python.
>
> M
Greg Ewing wrote:
> Travis E. Oliphant wrote:
>
>> I think this can be fixed easily by first checking the sequence slot for
>> a sq_concat function before calling PyNumber_InPlaceAdd.
>
> However, if this *is* fixed, it looks like it's going to
> break NumPy, in
Guido van Rossum wrote:
> On 3/27/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>> 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,
Paul Moore wrote:
> On 3/17/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>
>> Travis E. Oliphant wrote:
>>> Would it be possible to add at least the C-struct array interface to the
>>> Python arrayobject in time for Python 2.5?
>> I'm very much for
Nick Coghlan wrote:
> Travis E. Oliphant wrote:
>> Would it be possible to add at least the C-struct array interface to the
>> Python arrayobject in time for Python 2.5?
>
> Do you mean simply adding an __array_shape__ attribute that consists of a
> tuple with
Last year, during development of NumPy, the concept of the array
interface was developed as a means to share array_like data. It was
realized that it is this concept that needs to be explored further and
pushed into Python itself, rather than a particular incarnation of an
array.
It is very
Nick Coghlan wrote:
>
> And how...
>
>case Ellipsis_kind:
> ADDOP_O(c, LOAD_CONST, Py_Ellipsis, consts)
> break;
>
> Just a couple of minor details missing, like, oh, compiling the actual
> subscript operation :)
>
> Bug here: http://www.python.org/sf/1448804
>
> (assigned to my
I'm seeing strange behavior in the Python 2.5a0 trunk that is causing
the tests for numpy to fail. Apparently obj[...] = 1 is not calling
PyObject_SetItem
Here is a minimal example to show the error. Does anyone else see this?
class temp(object):
def __setitem__(self, obj, v):
Martin v. Löwis wrote:
> Neal Norwitz wrote:
>
>>I suppose that might be nice, but would require configure magic. I'm
>>not sure how it could be done on Windows.
>
>
> Contributions are welcome. On Windows, it can be hard-coded.
>
> Actually, something like
>
> #if SIZEOF_SIZE_T == SIZEOF_INT
Tim Peters wrote:
> [Travis Oliphant]
>
>>Maybe I have the wrong version of code. In my pyport.h (checked out
>>from svn trunk) I have.
>>
>>#define PY_SSIZE_T_MAX ((Py_ssize_t)(((size_t)-1)>>1))
>>
>>What is size_t?
>
>
> size_t is an unsigned integral type defined by, required by, and used
>
After some revisions, PEP 357 is ready for more comments. Please voice
any concerns.
-Travis
PEP: 357
Title: Allowing Any Object to be Used for Slicing
Version: $Revision: 42367 $
Last Modified: $Date: 2006-02-14 18:12:07 -0700 (Tue, 14 Feb 2006) $
Author: Travis Oliphant <[EMAIL PROTECTED]>
St
Guido van Rossum wrote:
> I'm about to send 6 or 8 replies to various salient messages in the
> PEP 332 revival thread. That's probably a sign that there's still a
> lot to be sorted out. In the mean time, to save you reading through
> all those responses, here's a summary of where I believe I stan
Thomas Wouters wrote:
> On Thu, Feb 09, 2006 at 02:32:47PM -0800, Brett Cannon wrote:
>
>>Looks good to me. Only change I might make is mention why __int__
>>doesn't work sooner (such as in the rationale). Otherwise +1 from me.
>
>
> I have a slight reservation about the name. On the one hand
Guido van Rossum wrote:
> On 2/9/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
>
> This is very close to acceptance. I think I'd like to see the patch
> developed and submitted to SF (and assigned to me) prior to
> acceptance.
>
>
>>Copyright
>>
>> This document is placed in the public dom
Guido van Rossum wrote:
> On 2/9/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
>
> BTW do you also still want to turn ZeroDivisionError into a warning
> (that is changed into an error by default)? That idea shared a slide
> and I believe it was discussed in the same meeting you & I and some
>
Attached is an updated PEP for 357. I think the index concept is better
situated in the PyNumberMethods structure. That way an object doesn't
have to define the Sequence protocol just to be treated like an index.
-Travis
PEP: 357357357
Title: Allowing any object to be used for slicing
Ver
Bengt Richter wrote:
>>
>
> How about if SLICE byte code interpretation would try to call
> obj.__int__() if passed a non-(int,long) obj ? Would that cover your use case?
>
I believe that this is pretty much what I'm proposing (except I'm not
proposing to use the __int__ method because it is alr
Bengt Richter wrote:
>>
>
> How about if SLICE byte code interpretation would try to call
> obj.__int__() if passed a non-(int,long) obj ? Would that cover your use case?
>
I believe that this is pretty much exactly what I'm proposing. The
apply_slice and assign_slice functions in ceval.c are c
Adam Olsen wrote:
> On 2/9/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
>>Guido seemed accepting to this idea about 9 months ago when I spoke to
>>him. I finally got around to writing up the PEP. I'd really like to
>>get this into Python 2.5 if possible.
>
>
> -1
>
> I've detailed my rea
Martin v. Löwis wrote:
> Travis E. Oliphant wrote:
>
>>Currently that means that they are "unicode" strings of basic size UCS2
>>or UCS4 depending on the platform. It is this duality that has some
>>people concerned. For all other data-types, NumPy allows t
This is a design question which is why I'm posting here. Recently the
NumPy developers have become more aware of the difference between UCS2
and UCS4 builds of Python. NumPy arrays can be of Unicode type. In
other words a NumPy array can be made of up fixed-data-length unicode
strings.
Cur
Martin v. Löwis wrote:
> Please let me know what you think.
>
> Regards,
> Martin
>
> PEP: XXX
> Title: Using ssize_t as the index type
> Version: $Revision$
> Last-Modified: $Date$
> Author: Martin v. Löwis <[EMAIL PROTECTED]>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
>
Armin Rigo wrote:
> Hi,
>
> Ok, here is the reason for the leak...
>
> There is in scipy a type called 'int32_arrtype' which inherits from both
> another scipy type called 'signedinteger_arrtype', and from 'int'.
> Obscure! This is not 100% officially allowed: you are inheriting from
> two C typ
Armin Rigo wrote:
> Hi,
>
> Ok, here is the reason for the leak...
>
> There is in scipy a type called 'int32_arrtype' which inherits from both
> another scipy type called 'signedinteger_arrtype', and from 'int'.
> Obscure! This is not 100% officially allowed: you are inheriting from
> two C typ
Armin Rigo wrote:
> Hi,
>
> Ok, here is the reason for the leak...
>
> There is in scipy a type called 'int32_arrtype' which inherits from both
> another scipy type called 'signedinteger_arrtype', and from 'int'.
> Obscure! This is not 100% officially allowed: you are inheriting from
> two C typ
69 matches
Mail list logo
