Guido van Rossum wrote:
> Please give the poor function a break. It was added to 2.5 and used
> only for indexing there. In 3.0 it is more generally useful (I want to
> use it whenever an int is needed). but in our pre-alpha code the error
> messages haven't been fixed yet. That's the whole story.
It was so nice to see many of you at PyCon this year. The event was
very well handled and congradulations are deserved all around.
I brought up the idea of the array interface several times. After I
heard Guido's keynote and saw the scheduled time-lines, I realized that
my approach should be
I'm sorry for creating two threads on the buffer protocol. I didn't see
the first one because I mistakenly put it as a reply to another thread.
This one is independent and should be more helpful as a discussion
place-holder.
-Travis
___
Python-300
>
>> 2. There is no way for a consumer to tell the protocol-exporting
>>object it is "finished" with its view of the memory and therefore no way
>>for the object to be sure that it can reallocate the pointer to the
>>memory that it owns (the array object reallocating its memory after
>>shar
Guido van Rossum wrote:
> On 2/25/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
>>Travis Oliphant wrote:
>>
>>
>>> 2. There is no way for a consumer to tell the protocol-exporting
>>>object it is "finished" with its view of the memory and therefore no way
>>>for the object to be sure that it can r
On 2/26/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I realized this thinking about the 3.0 bytes object, but the 2.x array
> > object has the same problems, and probably every other object that
> > uses the buffer API and has a mutable size (if there are any).
>
> Y
Guido van Rossum wrote:
> On 2/26/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
>>Guido van Rossum wrote:
>>
>>>I realized this thinking about the 3.0 bytes object, but the 2.x array
>>>object has the same problems, and probably every other object that
>>>uses the buffer API and has a mutable s
Guido van Rossum wrote:
> On 2/26/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
>>Guido van Rossum wrote:
>>
>
>
> Excellent. Are we all set then?
>
One more question? What is the reason for separate read/write getbuffer
calls. What is the problem with just one getbuffer call with a flag
On 2/26/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> One more question? What is the reason for separate read/write getbuffer
> calls. What is the problem with just one getbuffer call with a flag to
> indicate whether or not you want a writeable memory area?
I'm not sure; that API grew somewh
Hi all,
Daniel Stutzbach and I have prepared a draft PEP for the new IO system
for Python 3000. This document is, hopefully, true to the info that
Guido wrote on the whiteboards here at PyCon. This is still a draft
and there's quite a few decisions that need to be made. Feedback is
welcomed.
We'v
On 2/26/07, Mike Verdone <[EMAIL PROTECTED]> wrote:
> Daniel Stutzbach and I have prepared a draft PEP for the new IO system
> for Python 3000.
Thanks for doing this! Generally, it looks pretty good.
> Additionally, it defines a few other methods:
>
> (should these "is_" functions be attribut
Guido van Rossum wrote:
> In 3.0 it is more generally useful (I want to
> use it whenever an int is needed). but in our pre-alpha code the error
> messages haven't been fixed yet.
Okay, that's fine, thanks.
--
Greg
___
Python-3000 mailing list
Python-30
On 2/26/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 2/26/07, Mike Verdone <[EMAIL PROTECTED]> wrote:
> > Daniel Stutzbach and I have prepared a draft PEP for the new IO system
> > for Python 3000.
>
> Thanks for doing this! Generally, it looks pretty good.
Agreed. I made some changes to the
Travis Oliphant wrote:
> If they can't do it easily, then they don't have to define the
> release-function and Python will never call it.
The case I'm worried about is where the data can move,
so it really *needs* to be locked, yet the object has
no way of ensuring that. It would be impossible f
On 2/26/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Travis Oliphant wrote:
>
> > If they can't do it easily, then they don't have to define the
> > release-function and Python will never call it.
>
> The case I'm worried about is where the data can move,
> so it really *needs* to be locked, yet the
We implemented this at today's sprint. Andre wrote the transformations
for the 2to3 tools, I copied the raw_input() implementation from the
trunk back into the p3yk branch. Thanks Andre for your efforts in
writing the PEP, pushing for its implementation, and writing the
transformations!
--Guido
O
Nick Coghlan wrote:
> For example, simply
> replacing 'index' with 'integer' could lead to a different kind of
> confusion:
> TypeError: 'float' object cannot be interpreted as an integer
Maybe something like
TypeError: 'float' object cannot be used as an integer in this context
Or maybe
Josiah Carlson wrote:
> Greg Ewing <[EMAIL PROTECTED]> wrote:
>
>>$[68656C6C6F]
>
> I think it's a bad idea to choose a representation with any format that
> isn't able to do the eval(repr(obj)) loop.
The intention was for that to be a valid literal
syntax as well.
> It may be the case
> th
Greg Ewing wrote:
> Nick Coghlan wrote:
>> For example, simply
>> replacing 'index' with 'integer' could lead to a different kind of
>> confusion: TypeError: 'float' object cannot be interpreted as an
>> integer
>
> Maybe something like
>
>TypeError: 'float' object cannot be used as an in
19 matches
Mail list logo
