[matplotlib-devel] scatter docs
There was a question on the matplotlib-users list about symbols in scatter, that made me realize that the new "marker = (5,0)" ... syntax, that I contributed some time ago, were not documented. So I tried to write a doc string. Can anyone please check this and add the patch? Btw: shouldn't the "verts" keyword be removed, since marker=(verts,0) is equivalent ? Manuel Index: axes.py === --- axes.py (revision 4835) +++ axes.py (working copy) @@ -4144,10 +4144,22 @@ 'p' : pentagram 'h' : hexagon '8' : octagon - -If marker is None and verts is not None, verts is a sequence -of (x,y) vertices for a custom scatter symbol. - + +The marker can also be a tuple (numsides, style, angle), which will +create a custom, regular symbol. + +numsides is the number of sides + +style is the style of the regular symbol: + 0 : a regular polygon + 1 : a star-like symbol + 2 : an asterisk + +angle is the angle of rotation of the symbol + +Finally, marker can be (verts, 0), verts is a sequence of (x,y) +vertices for a custom scatter symbol. + s is a size argument in points squared. Any or all of x, y, s, and c may be masked arrays, in which - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] resurrecting namespace packages
Andrew Straw wrote: > Great -- hopefully that saved you some API re-arrangement pain. No > problem on shuffling mpl_sizer around -- please go ahead do it if you > have time. > > -Andrew > > Jeff Whitaker wrote: >> Andrew: Thanks, you've convinced me. Is it OK with you if I go >> ahead and make those changes to mplsizer at the same time I do basemap? >> >> -Jeff >> > Andrew: OK, the change to mpl_toolkits (which is now a proper namespace package) is all done. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX: (303)497-6449 NOAA/OAR/PSD R/PSD1Email : [EMAIL PROTECTED] 325 BroadwayOffice : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] resurrecting namespace packages
Could someone point me at a discussion/article that explains the need for namespace packages? I'm sure there is some good reason for it but on the surface it seems very confusing. I've always thought that the purpose of the __init__ file is to define the public interface for a package. So when you say: import foo You get foo defined in the way it should be. I'm not sure how doing : import foo.api as foo is an improvement. Whether the api is defined in __init__.py or api.py doesn't seem to matter (though I'm sure this is where I'm not understanding things...). I've googled and found references to needing to install and distribute sub-packages separately but that doesn't really seem to explain why __init__ can't be used in the sub-package. Is this primarily a limitation in the distribution and setup tools? Can someone shed some light on this for me? Ted At 08:11 AM 1/10/2008, Jeff Whitaker wrote: Andrew Straw wrote: > Great -- hopefully that saved you some API re-arrangement pain. No > problem on shuffling mpl_sizer around -- please go ahead do it if you > have time. > > -Andrew > > Jeff Whitaker wrote: >> Andrew: Thanks, you've convinced me. Is it OK with you if I go >> ahead and make those changes to mplsizer at the same time I do basemap? >> >> -Jeff >> > Andrew: OK, the change to mpl_toolkits (which is now a proper namespace package) is all done. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX: (303)497-6449 NOAA/OAR/PSD R/PSD1Email : [EMAIL PROTECTED] 325 BroadwayOffice : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] resurrecting namespace packages
Ted Drain wrote: > Could someone point me at a discussion/article that explains the need > for namespace packages? I'm sure there is some good reason for it but > on the surface it seems very confusing. I've always thought that the > purpose of the __init__ file is to define the public interface for a > package. So when you say: > > import foo > > You get foo defined in the way it should be. I'm not sure how doing : > > import foo.api as foo > > is an improvement. Whether the api is defined in __init__.py or > api.py doesn't seem to matter (though I'm sure this is where I'm not > understanding things...). I've googled and found references to > needing to install and distribute sub-packages separately but that > doesn't really seem to explain why __init__ can't be used in the > sub-package. Is this primarily a limitation in the distribution and > setup tools? > > Can someone shed some light on this for me? > > Ted Ted: I was wrong in my previous email - only the __init__.py in the top-level toolkits directory (now called mpl_toolkits) needs to be empty. So in the case of basemap, this means that the import has changed from from matplotlib.toolkits.basemap import Basemap to from mpl_toolkits.basemap import Basemap. We don't actually need to stuff things into an api.py file. -Jeff > > At 08:11 AM 1/10/2008, Jeff Whitaker wrote: >> Andrew Straw wrote: >> > Great -- hopefully that saved you some API re-arrangement pain. No >> > problem on shuffling mpl_sizer around -- please go ahead do it if you >> > have time. >> > >> > -Andrew >> > >> > Jeff Whitaker wrote: >> >> Andrew: Thanks, you've convinced me. Is it OK with you if I go >> >> ahead and make those changes to mplsizer at the same time I do >> basemap? >> >> >> >> -Jeff >> >> >> > >> Andrew: OK, the change to mpl_toolkits (which is now a proper namespace >> package) is all done. >> >> -Jeff >> >> -- >> Jeffrey S. Whitaker Phone : (303)497-6313 >> Meteorologist FAX: (303)497-6449 >> NOAA/OAR/PSD R/PSD1Email : [EMAIL PROTECTED] >> 325 BroadwayOffice : Skaggs Research Cntr 1D-124 >> Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg >> >> >> - >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace >> >> ___ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX: (303)497-6449 NOAA/OAR/PSD R/PSD1Email : [EMAIL PROTECTED] 325 BroadwayOffice : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] resurrecting namespace packages
Jeff Whitaker wrote: > Ted Drain wrote: >> Could someone point me at a discussion/article that explains the need >> for namespace packages? I'm sure there is some good reason for it but >> on the surface it seems very confusing. I've always thought that the >> purpose of the __init__ file is to define the public interface for a >> package. So when you say: >> >> import foo >> >> You get foo defined in the way it should be. I'm not sure how doing : >> >> import foo.api as foo >> >> is an improvement. Whether the api is defined in __init__.py or >> api.py doesn't seem to matter (though I'm sure this is where I'm not >> understanding things...). I've googled and found references to >> needing to install and distribute sub-packages separately but that >> doesn't really seem to explain why __init__ can't be used in the >> sub-package. Is this primarily a limitation in the distribution and >> setup tools? >> >> Can someone shed some light on this for me? >> >> Ted > > Ted: I was wrong in my previous email - only the __init__.py in the > top-level toolkits directory (now called mpl_toolkits) needs to be > empty. So in the case of basemap, this means that the import has > changed from > > from matplotlib.toolkits.basemap import Basemap > > to > > from mpl_toolkits.basemap import Basemap. > > We don't actually need to stuff things into an api.py file. But the reason you had to move to an independent mpl_toolkits package (which is a namespace package) is because mpl itself can't be a namespace package, because it has an __init__.py stuffed full of goodies. Right? Not that having an independent mpl_toolkits is a bad thing; it may make sense anyway. I think it simplifies the directory structure of basemap (which seemed needlessly deeply nested), doesn't it? Also, the namespace package constraint is inherent in distributing subpackages as eggs, correct? Without eggs there would be no such constraint. Subpackages would physically land in subdirectories of the main package upon installation. Eric - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] resurrecting namespace packages
Eric Firing wrote: > Jeff Whitaker wrote: >> Ted Drain wrote: >>> Could someone point me at a discussion/article that explains the >>> need for namespace packages? I'm sure there is some good reason for >>> it but on the surface it seems very confusing. I've always thought >>> that the purpose of the __init__ file is to define the public >>> interface for a package. So when you say: >>> >>> import foo >>> >>> You get foo defined in the way it should be. I'm not sure how doing : >>> >>> import foo.api as foo >>> >>> is an improvement. Whether the api is defined in __init__.py or >>> api.py doesn't seem to matter (though I'm sure this is where I'm not >>> understanding things...). I've googled and found references to >>> needing to install and distribute sub-packages separately but that >>> doesn't really seem to explain why __init__ can't be used in the >>> sub-package. Is this primarily a limitation in the distribution and >>> setup tools? >>> >>> Can someone shed some light on this for me? >>> >>> Ted >> >> Ted: I was wrong in my previous email - only the __init__.py in the >> top-level toolkits directory (now called mpl_toolkits) needs to be >> empty. So in the case of basemap, this means that the import has >> changed from >> >> from matplotlib.toolkits.basemap import Basemap >> >> to >> >> from mpl_toolkits.basemap import Basemap. >> >> We don't actually need to stuff things into an api.py file. > > But the reason you had to move to an independent mpl_toolkits package > (which is a namespace package) is because mpl itself can't be a > namespace package, because it has an __init__.py stuffed full of > goodies. Right? Not that having an independent mpl_toolkits is a bad > thing; it may make sense anyway. I think it simplifies the directory > structure of basemap (which seemed needlessly deeply nested), doesn't it? Eric: Yes, you're correct on both counts. > > Also, the namespace package constraint is inherent in distributing > subpackages as eggs, correct? Without eggs there would be no such > constraint. Subpackages would physically land in subdirectories of > the main package upon installation. Right again. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX: (303)497-6449 NOAA/OAR/PSD R/PSD1Email : [EMAIL PROTECTED] 325 BroadwayOffice : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
