Christian Heimes wrote:
> Yesterday I found a design problem in the array module. Travis Oliphant
> added a new typecode 'w' to the array module. 'w' is a wide unicode type
> that is guaranteed to be at least 4 bytes long. The 'u' typecode may be
> 2 bytes long.
>
> Unfortunately his change removed
Guido van Rossum wrote:
> On 9/11/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
>
>> I'm not sure I understand the difference between a classic read lock and
>> the exclusive write lock concept. Does the classic read-lock just
>> prevent writing to the
Jim Jewett wrote:
> On 9/11/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
>
>> Guido van Rossum wrote:
>>
>>> ... I'm hoping Travis has a particular way in mind of
>>> handling LOCKDATA that can be used as a template.
>>>
&
Guido van Rossum wrote:
> On 9/10/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
>
>>
>
> Hm, so this is completely different from what I thought. It seems you
> are describing the following:
>
> 1. acquire the buffer with LOCK_DATA
> 2. copy the data o
Guido van Rossum wrote:
> I'd like to see Travis's response to this. It's setting a precedent
> regarding locking objects in read-only mode; I haven't found other
> examples of objects using LOCKDATA (the only mentions of it seem to be
> rejecting it :). I keep getting confused by the two separate
Neal Norwitz wrote:
> On 8/18/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
>> In preparation for the sprints, I have converted all Python objects to
>> use the new buffer protocol PEP and implemented most of the C-API. This
>> work took place in the py3k-buffer
Hello all,
I'm sorry I won't be attending the Google sprints next week. I'm going
to be moving from Utah to Texas next week and will be offline for
several days.
In preparation for the sprints, I have converted all Python objects to
use the new buffer protocol PEP and implemented most of the
Hi everyone,
I apologize for my quietness on this list (I'm actually in the middle of
a move), but I recently implemented most of PEP 3118 in the py3k-buffer
branch (it's implemented but not tested...)
However, I'm running into trouble getting it to link. The compilation
step proceeds fine
Neal Norwitz wrote:
> On 8/11/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
>> However, I'm running into trouble getting it to link. The compilation
>> step proceeds fine but then I get a segmentation fault during the link
>> stage.
>
> The problem is
Hi everyone,
I apologize for my quietness on this list (I'm actually in the middle of
a move), but I recently implemented most of PEP 3118 in the py3k-buffer
branch (it's implemented but not tested...)
However, I'm running into trouble getting it to link. The compilation
step proceeds fine b
Forgive my ignorance, but I'm not really sure what this PEP is trying to
do. I don't want to sound negative, I really just don't understand the
purpose. I've just never encountered a problem this that I can see how
this PEP will help me solve.
That doesn't mean it's not worthwhile, I just do
Martin v. Löwis wrote:
> I'd like to submit the following PEP for Python 3.
>
> Regards,
> Martin
>
>
> PEP: xxx
> Title: Using UTF-8 as the default source encoding
> Version: $Revision $
> Last-Modified: $Date $
> Author: Martin v. Löwis <[EMAIL PROTECTED]>
> Status: Draft
> Type: Standards Tra
I know everybody is busy, but I would appreciate some kind of feedback
from Python developers about the attached extended buffer protocol which
I am proposing for Python 3k.
I am working on the changes to the struct module needed to accomodate
the enhanced syntax.
I'd like to know if I the
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
Attached is my revised PEP for the buffer protocol after incorporating
suggestions from Greg Ewing. It is as simple as I can make it and
still share what I think needs to be sharable. Suggestions are
welcome. I will provide and maintain code to implement the PEP when
the basic idea of t
Travis E. Oliphant wrote:
>
> Attached is my current draft of the enhanced buffer protocol for Python
> 3000. It is basically what has been discussed except for some issues
> with non single-segment memory areas (such as a sub-array).
>
> Comments are welcome.
>
The
Greg Ewing wrote:
>
> The buffer API is for the use of C code, and it should
> be designed with the convenience of C code in mind.
> Using Python data structures unnecessarily seems like
> the wrong way to go about that.
>
> The following alternative would seem to provide most of
> the things tha
Travis E. Oliphant wrote:
>
> The memory management is the only issue.
In fact, the PEP still has the issue of who manages the memory for the
format-description string when it is returned.
The easiest thing to do is to return a Python String and let reference
counting handle the
Greg Ewing wrote:
> Travis E. Oliphant wrote:
>
>> typedef char *(*formatbufferproc)(PyObject *view, int *itemsize)
>>
>> Get the format-string of the memory using the struct-module
>> string syntax
>
> I'm not sure whether a struct-for
Daniel Stutzbach wrote:
> I know I'm joining this discussion late in the game, so I apologize if
> my look through the list archives was not sufficiently exhaustive and
> this has been proposed and shot down before...
No, I don't think you are late. But this discussion has been going on
off and
Attached is my current draft of the enhanced buffer protocol for Python
3000. It is basically what has been discussed except for some issues
with non single-segment memory areas (such as a sub-array).
Comments are welcome.
-Travis Oliphant
PEP:
Title: Revising the buffer protocol
Version:
Guido van Rossum wrote:
> On 2/26/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> Great. I have no problem with this. Is your idea of locking the same
>> as mine (i.e. a function in the API for release?)
>
> Right.
My understanding of this locking mechanism would re
Guido van Rossum wrote:
> On 5/20/06, Talin <[EMAIL PROTECTED]> wrote:
>> As far as how to pick the set of operators, well my notion on that was
>
> I suggest you let this rest for now. We have plenty of existing
> operators, and I'd rather wait for a more compelling reason to add
> more.
>
I'm
Greg Ewing wrote:
> Travis E. Oliphant wrote:
>> The only thing I would wish different is to get rid of the PyGTK
>> dependency. I think PyGUI should be a wrapper directly on top of GNOME
>
> Perhaps you have Gnome and Gtk confused? Gnome is the
> desktop, Gtk is t
I'm sorry if this has been discussed before.
One of the things that is really nice about slice syntax is the ability
to construct slice objects to pass to __getitem__ using []
Would it be possible to extend the syntax so that slice syntax is
acceptable in more places in Python? In particular
Greg Ewing wrote:
> Travis E. Oliphant wrote:
>> Just get a
>> window-area from each platform's lowest-level tool and then draw your
>> widgets to the screen directly.
>
> But then you have something that looks totally non-native
> on all platforms. While it
Terry Reedy wrote:
> "Greg Ewing" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Terry Reedy wrote:
>>
>>> -the ability to ignore platforn standards and give an app a unique look
>>> and
>>> feel. A start on this, for instance, is being able to give dialog boxes
>>> a
>>> cust
27 matches
Mail list logo
