matplotlib-devel Mailing List for matplotlib

On 5/26/06, Eric Firing <ef...@ha...> 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=3D'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.

I've used this instead in the past:

class NotGiven: pass

def foo(x,y=3DNotGiven):
  if y is NotGiven:
    y =3D smart_default
  elif y is None:
    y =3D 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 Friday 26 May 2006 14:01, Eric Firing wrote:
> 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...

> '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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- 
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853

dd...@co...
office: (607) 255-9894
fax: (607) 255-9001

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

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

Chr...@no...

John Hunter wrote:
>>>>>>"Christopher" == Christopher Barker <Chr...@no...> writes:
> 
> 
>     Christopher> 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.
> 
>     Christopher> and really, really prone to error. If you need to use
>     Christopher> a string, use something else, like perhaps
>     Christopher> "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.
> 
>     Christopher> That's actually a good thing. I like to think of a
>     Christopher> polygon with a border a single object, and it can
>     Christopher> dome in handy if you want to do something like draw a
>     Christopher> polygon with a border that is
>     Christopher> semi-transparent. drawing the fill and the stroke
>     Christopher> 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

>>>>> "Christopher" == Christopher Barker <Chr...@no...> writes:

    Christopher> 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.

    Christopher> and really, really prone to error. If you need to use
    Christopher> a string, use something else, like perhaps
    Christopher> "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.

    Christopher> That's actually a good thing. I like to think of a
    Christopher> polygon with a border a single object, and it can
    Christopher> dome in handy if you want to do something like draw a
    Christopher> polygon with a border that is
    Christopher> semi-transparent. drawing the fill and the stroke
    Christopher> independently doesn't work right. I was recently
    Christopher> messing around with this in Cairo, and it's a pain
    Christopher> int eh *&^, but it can be done right, but it's up to
    Christopher> 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:
> 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"


> 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.

-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

Chr...@no...