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
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
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
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
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
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, 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
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, 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
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, 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
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
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
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/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
>
>> 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
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
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
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.
19 matches
Mail list logo
