John Hunter wrote:
>> mean "do the default". The hack workaround we use here is to
>> set 'None' (the string) rather than None itself. Ugly, yes.
> and really, really prone to error. If you need to use
> a string, use something else, like perhaps
> "transparent"
How is it really prone to error -- I would think that if the user pass
es 'None', the string, for a color arg, there aren't too many
alternative meanings.
>> The real root of the problem is that renderer.draw_polygon(gc,
>> rgbFace, tverts) is overloaded to support edge and face drawing
>> in one function call.
> That's actually a good thing. I like to think of a
> polygon with a border a single object, and it can
> dome in handy if you want to do something like draw a
> polygon with a border that is
> semi-transparent. drawing the fill and the stroke
> independently doesn't work right. I was recently
> messing around with this in Cairo, and it's a pain
> int eh *&^, but it can be done right, but it's up to
> the back-end to figure out how.
You may be right -- it may be a good thing -- what we need is a clear
way to say "edge on" or "face on". One way is to figure out a way to
do it with the color specification itself ('None' or something like
it). Another way is to add boolean flags to the gc object...
JDH
John Hunter wrote:
"Christopher" == Christopher Barker <Chris.Barker@...236...> writes:
> John Hunter wrote:
>> mean "do the default". The hack workaround we use here is to
>> set 'None' (the string) rather than None itself. Ugly, yes.
> and really, really prone to error. If you need to use
> a string, use something else, like perhaps
> "transparent"
How is it really prone to error -- I would think that if the user pass
es 'None', the string, for a color arg, there aren't too many
alternative meanings.
Right. 'None' means no color--don't draw it. 'Transparent' is longer, and conceptually closer to alpha=0. The only potential error is typing 'None' instead of None, or the reverse. It could be confusing to a new user.
>> The real root of the problem is that renderer.draw_polygon(gc,
>> rgbFace, tverts) is overloaded to support edge and face drawing
>> in one function call.
> That's actually a good thing. I like to think of a
> polygon with a border a single object, and it can
> dome in handy if you want to do something like draw a
> polygon with a border that is
> semi-transparent. drawing the fill and the stroke
> independently doesn't work right.
[....]
You may be right -- it may be a good thing -- what we need is a clear
way to say "edge on" or "face on". One way is to figure out a way to
do it with the color specification itself ('None' or something like
it). Another way is to add boolean flags to the gc object...
But the gc object is at a lower level, not exposed to the user, so something like "color='None'" or "linewidth=0" is needed in any case at the higher levels, isn't it? Or were you thinking of adding another kwarg to the high-level functions, that would be passed down the line into the backend? Something like draw=face|edge|both?
Now I see the problem with linewidth=0; it solves only half the problem, turning off the boundary rendering, but does not facilitate the reverse, leaving the interior unfilled but drawing the boundary.
Eric
Eric Firing wrote:
John Hunter wrote:
How is it really prone to error -- I would think that if the user pass
es 'None', the string, for a color arg, there aren't too many
alternative meanings.
Right. 'None' means no color--don't draw it. 'Transparent' is longer, and conceptually closer to alpha=0. The only potential error is typing 'None' instead of None, or the reverse. It could be confusing to a new user.
Or an old user. If I see 'None" in the docs, I'm going to type None. It seems like a really bad idea to have both 'None' and None be valid, but have different meanings.
If you don't like 'Transparent', how about 'NoLine', "Invisible", 'No', etc, etc...... but please don't use 'None'
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@...236...
Christopher Barker wrote:
Eric Firing wrote:
John Hunter wrote:
How is it really prone to error -- I would think that if the user pass
es 'None', the string, for a color arg, there aren't too many
alternative meanings.
Right. 'None' means no color--don't draw it. 'Transparent' is longer, and conceptually closer to alpha=0. The only potential error is typing 'None' instead of None, or the reverse. It could be confusing to a new user.
Or an old user. If I see 'None" in the docs, I'm going to type None. It seems like a really bad idea to have both 'None' and None be valid, but have different meanings.
If you don't like 'Transparent', how about 'NoLine', "Invisible", 'No', etc, etc...... but please don't use 'None'
OK, I agree now; let's move away from 'None' as a string. It can be done gradually. The brevity of 'No' is appealing, and it also works as the first two letters of 'None' (so it is extra-easy to support both), but the grammar of "color='No'" is poor. 'Invisible' is still a bit long. 'Absent' could work. So could 'Blank', although for French and Spanish speakers it is perilously close to their word for white. Maybe 'No' really is the best compromise.
Eric
Christopher Barker wrote:
> Eric Firing wrote:
>> John Hunter wrote:
>>> How is it really prone to error -- I would think that if the user pass
>>> es 'None', the string, for a color arg, there aren't too many
>>> alternative meanings.
>>
>> Right. 'None' means no color--don't draw it. 'Transparent' is
>> longer, and conceptually closer to alpha=0. The only potential error
>> is typing 'None' instead of None, or the reverse. It could be
>> confusing to a new user.
>
> Or an old user. If I see 'None" in the docs, I'm going to type None. It
> seems like a really bad idea to have both 'None' and None be valid, but
> have different meanings.
>
> If you don't like 'Transparent', how about 'NoLine', "Invisible", 'No',
> etc, etc...... but please don't use 'None'
OK, I agree now; let's move away from 'None' as a string. It can be
done gradually. The brevity of 'No' is appealing, and it also works as
the first two letters of 'None' (so it is extra-easy to support both),
but the grammar of "color='No'" is poor.
Its not too bad, if in this case you recognize color as a verb instead of a
noun...
···
On Friday 26 May 2006 14:01, Eric Firing wrote:
'Invisible' is still a bit
long. 'Absent' could work. So could 'Blank', although for French and
Spanish speakers it is perilously close to their word for white. Maybe
'No' really is the best compromise.
Eric
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
--
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853
dd55@...143...
office: (607) 255-9894
fax: (607) 255-9001
I've used this instead in the past:
class NotGiven: pass
def foo(x,y=NotGiven):
if y is NotGiven:
y = smart_default
elif y is None:
y = do_the_rigth_thing_for_None
...
This lets None be a valid value without the joyfully robust choice of
None and 'None' having drastically different meanings.
Just an idea..
f
···
On 5/26/06, Eric Firing <efiring@...229...> wrote:
OK, I agree now; let's move away from 'None' as a string. It can be
done gradually. The brevity of 'No' is appealing, and it also works as
the first two letters of 'None' (so it is extra-easy to support both),
but the grammar of "color='No'" is poor. 'Invisible' is still a bit
long. 'Absent' could work. So could 'Blank', although for French and
Spanish speakers it is perilously close to their word for white. Maybe
'No' really is the best compromise.