[Python-Dev] Add pure python PNG writer module to stdlib?

[Johann C. Rocholl]

> > Does anybody find this idea interesting?
>
> Yes, although I wouldn't want an interface taking in strings but something
> more like an iterator that returns each row which itself contains int
> triples.  In other words more array-based than string based.

I agree that arrays would be semantically closer to the concept of
scanlines of pixel values. OTOH, I have my reasons for choosing the
string interface:

1. String is what you get from any file-like object with file.read(),
be it a PPM file on disk, or a pipe like this: os.popen('djpeg
test.jpg')
2. String is unbeatable in terms of efficiency.
3. Everybody knows how to use strings.
4. String can easily be created from other representations, for example:

>>> from array import array
>>> B = array('B')
>>> B.extend((255, 255, 255))
>>> B.tostring()
'\xff\xff\xff'

> > Does anybody think it could go into stdlib before the feature freeze for
> 2.5?
>
> Nope.  To get added to the stdlib there needs to be support from the
> community that the module is useful and best-of-breed.  Try posting on
> c.l.py and see if people pick it up and like it.  No way that is going to
> happen before b1.  But there is always 2.6 .

That's what I thought. My remote hope was that there would be
immediate concensus on python-dev about both the 'useful' and
'best-of-breed' parts. Anybody else with a +1? ;-)

Seriously, it's totally fine with me if the module doesn't make it
into 2.5, or even if it never makes it into stdlib. I'm just offering
it with some enthusiasm.

Cheers,
Johann