> > 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
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
