"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Joe Smith wrote:
>> If the maintainers of most of the large packages that do imaging are
>> willing
>> to support this,
>> and your code is good, I see absolutely no reason why this PEP would not
>> be
>> accepted.
>
> S
Joe Smith wrote:
> If the maintainers of most of the large packages that do imaging are willing
> to support this,
> and your code is good, I see absolutely no reason why this PEP would not be
> accepted.
Something that bothers me about it a little is that
the core Python/C API seems like the wr
"Lino Mastrodomenico" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>2007/7/1, BJörn Lindqvist <[EMAIL PROTECTED]>:
>> But I cannot see how it would solve the problem with to many image
>> classes. The reason why PIL, PyGame and wxPython has different image
>> classes is because eac
Reference Implementation
If this PEP is accepted, the author will provide a reference
implementation of the new classes in pure Python (that can run in
CPython, PyPy, Jython and IronPython) and a second one optimized for
speed in Python and C, suitable for inclusion in th
Hi Lino,
On 7/1/07, Lino Mastrodomenico <[EMAIL PROTECTED]> wrote:
> ``__getitem__(integer) -> line``
>
> Returns the line at the specified (y) position.
Just some ideas to think about.
1) Have you considered adding a separate lines property to the Image protocol?
2) Does one, by default, w
2007/7/1, BJörn Lindqvist <[EMAIL PROTECTED]>:
> But I cannot see how it would solve the problem with to many image
> classes. The reason why PIL, PyGame and wxPython has different image
> classes is because each of them use different C functions for
> manipulating said image classes. These differe
>> The only way to get compatibility between the libraries is to create
>> an image library in C _and_ get those libraries to start using it.
>>
>
> They'll all quack the same way. (This is paraphrased in the PEP's
> abstract, as far as I read it.)
To the Python side, yes. But to the underlying
BJörn Lindqvist schrieb:
> Cool PEP! I really love the API for the Image class. A standard Image
> class would be a useful addition to the standard library.
>
> But I cannot see how it would solve the problem with to many image
> classes. The reason why PIL, PyGame and wxPython has different image
Cool PEP! I really love the API for the Image class. A standard Image
class would be a useful addition to the standard library.
But I cannot see how it would solve the problem with to many image
classes. The reason why PIL, PyGame and wxPython has different image
classes is because each of them us
Here's the full text of the PEP's current draft, so you can comment
directly on it (thanks to Collin Winter for the suggestion):
PEP: 368
Title: Standard image protocol and class
Version: $Revision: 56133 $
Last-Modified: $Date: 2007-06-30 21:07:03 +0200 (sab, 30 giu 2007) $
Author: Lino Mastrodom
Robert Kern wrote:
> Lino Mastrodomenico wrote:
>> Hi everyone,
>>
>> I have submitted a new PEP:
>>
>> http://www.python.org/dev/peps/pep-0368/
>>
>> It starts from a Pete Shinners' suggestion and from the consideration
>> that there are a lot of Python libraries that use image objects, but
>>
Lino Mastrodomenico wrote:
> Hi everyone,
>
> I have submitted a new PEP:
>
> http://www.python.org/dev/peps/pep-0368/
>
> It starts from a Pete Shinners' suggestion and from the consideration
> that there are a lot of Python libraries that use image objects, but
> almost all of them have im
Hi everyone,
I have submitted a new PEP:
http://www.python.org/dev/peps/pep-0368/
It starts from a Pete Shinners' suggestion and from the consideration
that there are a lot of Python libraries that use image objects, but
almost all of them have implemented their own image classes,
incompatib
13 matches
Mail list logo
