Re: [Python-Dev] Standard Image and Sound classes (was: SoC proposal: multimedia library)

2007-03-27 Thread Anthony Baxter
On Tuesday 27 March 2007 11:03, Lino Mastrodomenico wrote:
 2007/3/26, Pete Shinners [EMAIL PROTECTED]:
  My main question is what is the image and sound container
  passed back to Python? This single thing along would be worth a
  SoC if it could be implemented across all libraries.
 
  Will your image objects be transferrable to PIL, Pygame,
  PyOpengl, Numpy, Pythonmagick, Pycairo, wxPython, etc? It would
  be best if this could avoid the fromstring/tostring mojo that
  always requires and extra copy of the data for each transfer.

 I agree. I withdrew my original multimedia library idea and
 submitted a proposal for the creation of two standard Image and
 Sound classes.

Ideally you'd hook this into the standard library's existing sound 
file handling modules.

Anthony
-- 
Anthony Baxter [EMAIL PROTECTED]
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Standard Image and Sound classes (was: SoC proposal: multimedia library)

2007-03-27 Thread Lino Mastrodomenico
2007/3/27, Anthony Baxter [EMAIL PROTECTED]:
 On Tuesday 27 March 2007 11:03, Lino Mastrodomenico wrote:
  I agree. I withdrew my original multimedia library idea and
  submitted a proposal for the creation of two standard Image and
  Sound classes.

 Ideally you'd hook this into the standard library's existing sound
 file handling modules.

Yes, in my SoC application I listed the following stdlib modules (for
both sound and images): Tkinter, Tix, wave, ossaudiodev, winsound,
aifc, audioop, sunau, sunaudiodev and imageop.

There are also a few Mac modules that can probably use the new
classes: videoreader, PixMapWrapper and some Carbon modules.

IRIX goodness: al, imgfile, jpeg and gl, but I can't test these. BTW,
will they be still here in Python 3.0?

-- 
Lino Mastrodomenico
E-mail: [EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Standard Image and Sound classes (was: SoC proposal: multimedia library)

2007-03-27 Thread Lino Mastrodomenico
2007/3/28, Lino Mastrodomenico [EMAIL PROTECTED]:
 IRIX goodness: al, imgfile, jpeg and gl, but I can't test these. BTW,
 will they be still here in Python 3.0?

Ok, I found the answer: PEP 3108. Sorry for the noise.

-- 
Lino Mastrodomenico
E-mail: [EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Standard Image and Sound classes (was: SoC proposal: multimedia library)

2007-03-26 Thread Lino Mastrodomenico
2007/3/26, Pete Shinners [EMAIL PROTECTED]:
 My main question is what is the image and sound container passed back to 
 Python?
 This single thing along would be worth a SoC if it could be implemented across
 all libraries.

 Will your image objects be transferrable to PIL, Pygame, PyOpengl, Numpy,
 Pythonmagick, Pycairo, wxPython, etc? It would be best if this could avoid the
 fromstring/tostring mojo that always requires and extra copy of the data for
 each transfer.

I agree. I withdrew my original multimedia library idea and
submitted a proposal for the creation of two standard Image and Sound
classes.

If the PSF accepts my proposal and if Google grants a student slot for
me, I will try to implement an interface for the two classes that can
work well for everyone and be easily usable from both the Python and
the C side. I guess this will require a PEP, if this is the case I
will volunteer to write it.

And, most important, I will create patches for the appropriate
standard library modules and for a lot of external libraries, to try
to make the use of the two new classes really interoperable.

Finally, as Greg suggested, adding the new buffer interface to the two
classes can be a really good idea. I'm following with interest that
discussion.

Keeping fingers crossed...

-- 
Lino Mastrodomenico
E-mail: [EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com