> > 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4