Hi,
On 22.06.06, John Owens wrote:
> In the meantime, before we maybe settle on a final useful abstraction
> that works for everyone, can we try something that leaves the
> implementation to the programmer? What would be needed is a
> class that takes a data structure and a function as an argument,
> both supplied by the programmer. The function should take "index"
> and "n_indices" as an argument and access the data structure. It's
> the same interface as the current gradient class, except the data
> structure is hardwired. It's specifically because I didn't have access
> to such a function/data structure pairing that I brought this whole
> issue up in the first place. Perhaps the data structure should be
> limited to a dictionary to start with.
I'm not convinced at all that this is a good idea. A changeable
attribute is something quite complicated to the regular PyX user
already. Sure, there is this funny feature of a gradient (I've already
switched my mind to the new notation -- which I like very much and
which I'm thankful we've already reached this). But a gradient is
something special. A silly and simple changeable attribute should be
flat. Try
python -c 'import this'|sed -e '7!d'
Really. We should not complicate that. And I would very much dislike a
palette to return some very stange different colors depending on
certain strange settings.
Overall, if we really want something like you suggest (and sure, I'm
convinced it's a usefull feature), we should make something like a
changeable attribute, which delegates the selection to some other
changeable attribute. Something along the lines:
class palette(attr.changelist):
pass
palette.x3 = palette([c31, c32, c33])
palette.x4 = palette([c41, c42, c43, c44])
palette.x5 = palette([c51, c52, c53, c54, c55])
class discretesomething(attr.changeattr):
__init__(self, palettes):
self.palettes = palettes
select(self, index, total):
return self.palettes[total].select(index, total)
discretesomething.x = discretesomething({3: palette.x3,
4: palette.x4,
5: palette.x5})
Yeah. That's certainly possible, but it's a feature build for
convenience *on* *top* of the basic infrastructure. And the
"discretesomething" is a strange object. It's a changeable attribute,
sure. But it's not a palette, since for example there are colors which
can be selected, which should *not* be used together. And it's not a
gradient, since the color is not a function of a single parameter.
So overall I don't see any problem. We seems to have learned that we
wont something like this. The discretesomething should be something
general and should live in attr.py ... we only need a name for that.
And then we could create instances for the colorbrewer.org palettes,
except for the problem, that we're not allowed to do so.
André
--
by _ _ _ Dr. André Wobst
/ \ \ / ) [EMAIL PROTECTED], http://www.wobsta.de/
/ _ \ \/\/ / PyX - High quality PostScript and PDF figures
(_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
PyX-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyx-devel
