Phoenix - floatcanvas doc and tests
2 views
Skip to first unread message
Werner
May 9, 2013, 3:53:53 AM5/9/13
to wxpyth...@googlegroups.com
Hi Chris and Robin,
Attached is an initial patch for documentation (please don't apply it),
Chris can you have a quick look over it and let me know if the method
param descriptions are correct, especially for things like XY and WH as
they will repeat. Don't worry about Sphinx formatting at this point.
My plan is to document all the public methods, while I am doing this I
also clean up some of the spacing inconsistency (hope this is fine with
you).
I also enclosed the tests I started on, I was thinking of adding one for
each draw object. Should I make two files, one for the NavCanvas based
tests and one for the FloatCanvas ones or are the ones using
FloatCanvas enough with just the ctor test for NavCanvas.
What other things should be tested, not that I promise to do them, but I
will try:-) and do at least some of them.
Werner
Attached is an initial patch for documentation (please don't apply it),
Chris can you have a quick look over it and let me know if the method
param descriptions are correct, especially for things like XY and WH as
they will repeat. Don't worry about Sphinx formatting at this point.
My plan is to document all the public methods, while I am doing this I
also clean up some of the spacing inconsistency (hope this is fine with
you).
I also enclosed the tests I started on, I was thinking of adding one for
each draw object. Should I make two files, one for the NavCanvas based
tests and one for the FloatCanvas ones or are the ones using
FloatCanvas enough with just the ctor test for NavCanvas.
What other things should be tested, not that I promise to do them, but I
will try:-) and do at least some of them.
Werner
werner
May 11, 2013, 6:07:46 AM5/11/13
to wxPyth...@googlegroups.com
Hi,
Attached a file with unittests for floatcanvas, all tests pass for me,
but I think they are a bit basic, create a canvas and add an object. I
think I got all object types covered, but it would be nice to enhance
them to have each object type exercise all parameters and probably some
more.
The patch is mainly documentation, plus one real fix to get the tests to
pass (wx._gdi.Bitmap and wx._core.Image) and some spacing "corrections".
I have marked things with "???" where I am very unsure about things
and/or where I have to go back and clean up.
Comments and suggestions for improvements are welcome.;-)
Werner
Attached a file with unittests for floatcanvas, all tests pass for me,
but I think they are a bit basic, create a canvas and add an object. I
think I got all object types covered, but it would be nice to enhance
them to have each object type exercise all parameters and probably some
more.
The patch is mainly documentation, plus one real fix to get the tests to
pass (wx._gdi.Bitmap and wx._core.Image) and some spacing "corrections".
I have marked things with "???" where I am very unsure about things
and/or where I have to go back and clean up.
Comments and suggestions for improvements are welcome.;-)
Werner
Chris Barker - NOAA Federal
May 13, 2013, 12:15:33 PM5/13/13
to wxPyth...@googlegroups.com
Werner,
* SetHitBrush() and SetHitPen() are really designed to by only called internally -- maybe a note to that effect (I suppose they should be named with a leading underscore...)
* def SetColor(self, Color):
+ """
+ Set the Color - this method is overridden in the subclasses
+
+ :param `Color`: Use one of the following values or ``None`` :
+
+ - ``Green``
+ - ``White``
+ - ``Black``
+ - ``Grey``
+ - ``MediumGrey``
+ - ``LightGrey``
+ - ``Cyan``
+ - ``Red``
+
*
class RectEllipse(XYObjectMixin, LineAndFillMixin, DrawObject):
+ """A RectEllipse draw object."""
* :param `XY`: takes a 2-tuple, or a (2,) `NumPy <http://www.numpy.org/>`_
Looking at the doc patch now -- it looks great. I"ve lost track of what I'd apply this patch to, so I'll just comment here:
A few notes:
* SetHitBrush() and SetHitPen() are really designed to by only called internally -- maybe a note to that effect (I suppose they should be named with a leading underscore...)
* def SetColor(self, Color):
+ """
+ Set the Color - this method is overridden in the subclasses
+
+ :param `Color`: Use one of the following values or ``None`` :
+
+ - ``Green``
+ - ``White``
+ - ``Black``
+ - ``Grey``
+ - ``MediumGrey``
+ - ``LightGrey``
+ - ``Cyan``
+ - ``Red``
+
You can use any of the names colors in the wx named color database -- maybe a link to that somewhere? Why I pre-populated with that particula rset of colors, I have no idea!
Same for anywhere a color is used, of course.
You can also use a tuple of RGB values (I'm pretty sure!) -- i.e. anything hashable that wx.Pen and wx.Brush understand.
class RectEllipse(XYObjectMixin, LineAndFillMixin, DrawObject):
+ """A RectEllipse draw object."""
RectEllipse is used as a subclass for the Rectangle and Ellipse objects -- it does nothing on its own.
We may want to add:
:param `XY`: the (x,y) coordinate of the corner of the rectangle or ellipse -- a 2-tuple, or a (2,) `NumPy <http://www.numpy.org/>`_
Similarly for all objects that take an "XY" -- it's always a point ,but what point depends on the object -- i.e the corner of a rect, the center of a circle, etc.
Thanks for doing this! It's been on my list for long time, but clearly I never found the time to do it!
I also enclosed the tests I started on, I was thinking of adding one for each draw object. Should I make two files, one for the NavCanvas based tests and one for the FloatCanvas ones or are the ones using FloatCanvas enough with just the ctor test for NavCanvas.
pretty much - yes, NavCanvas doesn't add much. Ideally, we'd test that clicking on the toolbar buttons does the right thing, but I'm not sure how to do that -- GUI testing is a pain.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris....@noaa.gov
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris....@noaa.gov
werner
May 13, 2013, 12:59:25 PM5/13/13
to wxPyth...@googlegroups.com
On 13/05/2013 18:15, Chris Barker - NOAA Federal wrote:
> Werner,
>
> Looking at the doc patch now -- it looks great. I"ve lost track of
> what I'd apply this patch to,
I work against this repo:
> Werner,
>
> Looking at the doc patch now -- it looks great. I"ve lost track of
> what I'd apply this patch to,
http://svn.wxwidgets.org/svn/wx/wxPython/Phoenix/trunk
If Robin or you could apply it then I can review the end result of the
Sphinx doc (I do an initial check locally but only building wxlib doc I
can't see if links to other stuff are correct or not).
> so I'll just comment here:
and handle your comments then. There is also quit a bit to be done to
FloatCanvas methods, will work on those too.
...
> pretty much - yes, NavCanvas doesn't add much. Ideally, we'd test that
> clicking on the toolbar buttons does the right thing, but I'm not sure
> how to do that -- GUI testing is a pain.
I don't know if we can UI testing.
> clicking on the toolbar buttons does the right thing, but I'm not sure
> how to do that -- GUI testing is a pain.
I guess there other non UI tests which could still be added, e.g.:
- delete of object
- group stuff
- ?
I will first continue on the doc and try to get that as close to finish
as possible, if someone else wants to attack unittests that would be great.
Werner
Chris Barker - NOAA Federal
May 13, 2013, 1:15:12 PM5/13/13
to wxPyth...@googlegroups.com
On Sat, May 11, 2013 at 3:07 AM, werner <wbr...@free.fr> wrote:
>
> Attached a file with unittests for floatcanvas,
>
> Attached a file with unittests for floatcanvas,
very cool!
Robin, are you using nose or pytest, or just plain old unitttest? (I'm kind of a fan of pytest..)
I don't have imp_unitest or wtc -- Phoenix stuff?
so not running, but reading...
Robin, are you using nose or pytest, or just plain old unitttest? (I'm kind of a fan of pytest..)
I don't have imp_unitest or wtc -- Phoenix stuff?
so not running, but reading...
> all tests pass for me, but I think they are a bit basic, create a canvas and add an object. I think I got all object types covered, but it would be nice to enhance them to have each object type exercise all parameters and probably some more.
>
yup -- but basic or not, knowing that all the DRawObjects can be created without a crash is a big step up!
Another level would be some of the methods like .Move() and .CalcBoundingBox, etc -- we could check if the geometry of the object was computed properly.
It seems some of this could be done with auto-generated tests -- so we can apply the same test to multiple DrawObject types, for instance. That's a bit klunky with unittest, I think -- one reason I like pytest (or nose)
Of course, the real question is if the object actually gets displayed properly -- but I don't know if we want to go there!
Another level would be some of the methods like .Move() and .CalcBoundingBox, etc -- we could check if the geometry of the object was computed properly.
It seems some of this could be done with auto-generated tests -- so we can apply the same test to multiple DrawObject types, for instance. That's a bit klunky with unittest, I think -- one reason I like pytest (or nose)
Of course, the real question is if the object actually gets displayed properly -- but I don't know if we want to go there!
>
> The patch is mainly documentation, plus one real fix to get the tests to pass (wx._gdi.Bitmap and wx._core.Image) and some spacing "corrections".
>
> I have marked things with "???" where I am very unsure about things and/or where I have to go back and clean up.
looking for the ???:
the event types supported for DrawObject.Bind are:
EVT_FC_LEFT_DOWN
EVT_FC_LEFT_UP
EVT_FC_LEFT_DCLICK
EVT_FC_MIDDLE_DOWN
EVT_FC_MIDDLE_UP
EVT_FC_MIDDLE_DCLICK
EVT_FC_RIGHT_DOWN
EVT_FC_RIGHT_UP
EVT_FC_RIGHT_DCLICK
EVT_FC_ENTER_OBJECT
EVT_FC_LEAVE_OBJECT
The others only apply to the Canvas as a whole, not to individual objects.
+ :param integer `LineWidth`: the width in pixels ???
yes -- pixels is correct.
+ :param integer `Direction`: angle of arrow in degrees, zero is straight
+ up +angle is to the right (theta) ????
correct, but don't need the (theta) -- I think I changed the namem in there at soem point...
def FindClosestPoint(self, XY):
"""
@@ -907,6 +1164,8 @@
This can be used to figure out which point got hit in a mouse
binding callback, for instance. It's a lot faster that using a
lot of separate points.
+
+ :param `XY`: takes a 2-tuple in World coordinates ???
let's try:
:param `XY`: the (x,y) coordinates of the point to look for--takes a 2-tuple or (2,) numpy array in World coordinates
+class Text(TextObjectMixin, DrawObject):
+ """Draws a text object
+
+ ??? do we integrate all this below or ...???
+
yes, I think that all belongs in the constructor docstring.
class ScaledTextBox(TextObjectMixin, DrawObject):
"""
+ ??? what to do with this ??? should it be moved to the appropiate param???
+
This class creates a TextBox object that is scaled when zoomed. It is
placed at the coordinates, x,y.
yes, other than the quick high-level description:
"a multi-line TextBox, which is scaled when zoomed."
The rest should go in the __init__ and/or appropriate methods.
+ :param `Point`: takes a 2-tuple ???
+ :param integer `Size`: size in World pixels ???
opps -- World units.
+ :param `Color`: see :meth:`~lib.floatcanvas.FloatCanvas.DrawObject.SetColor`
+ :param `BackgroundColor`: see :meth:`~lib.floatcanvas.FloatCanvas.DrawObject.SetColor`
+ :param `LineColor`: see :meth:`~lib.floatcanvas.FloatCanvas.DrawObject.SetColor`
+ :param `LineWidth`: see :meth:`~lib.floatcanvas.FloatCanvas.DrawObject.SetLineWidth`
+ :param `Width`: width in pixels or ``None`` ???
yes, this is in pixels (Or None...)
+ :param `PadSize`: padding in pixles or ``None`` ???
This is in World units.
class FloatCanvas(wx.Panel):
"""
- FloatCanvas.py
-
- This is a high level window for drawing maps and anything else in an
- arbitrary coordinate system.
-
+ Do we want this duplicated here???
+
No, that should all be in one place.
+ Default class constructor.
+
+ :param Window `parent`: parent window. Must not be ``None``;
+ :param integer `id`: window identifier. A value of -1 indicates a default value;
+ :param `size`: a tuple or :class:`Size`
+ :param `ProjectionFun`: a custom projection function ???
This allows you to change the transform from world to pixel coordinates. We can point to FloatCanvas.FlatEarthProjection for an example -- though that should really be a class method, or even better, simply a function in the module. There is a tiny bit on info in the error message in FloatCanvas.SetProjectionFun()
(Note: this really should get re-factored to allow more generic projections...)
+ :param string `BackgroundColor`: any value accepted by :class:`Brush`
+ :param `Debug`: activate debug ???
this turns on a smattering of print statements.. not that many really, but we could do more with that.
def FlatEarthProjection(self, CenterPoint):
+ """Set the CenterPoint for FlatEarthProjection ???
+
+ :param `CenterPoint`: takes a 2-tuple, or a (2,)
+ `NumPy <http://www.numpy.org/>`_ array of point coordinates???
+
+ """
let's try:
"""
compute the scaling array for the flat-earth projection
:param `CenterPoint`: center point of viewport (lon, lat) -- the longitude is scaled to the latitude of this point. a 2-tuple, or a (2,) `NumPy <http://www.numpy.org/>`_ array of point coordinates
:returns : a (2,) numpy array that scales world coordinates. This scaling is applied when converting to-from world to pixel coordinates.
"""
def AddToolbarModeButtons(self, tb, Modes):
+ """
+ Add the mode buttons to the tool bar.
+
+ :param ToolBar `tb`: the toolbar instance
+ :param list `Modes`: a list of modes to add ??? what is valid ???
+
+ """
There are the modes defined in GUIMode.py, but the user can define their own, as well.
def Bind(self, Event, CallBackFun):
+ """
+ Bind an event to the DrawObject
+
+ :param `Event`: see below for supported event types ???
I think I covered this in the last email, but I think this is it.
+ - EVT_FC_LEFT_DOWN
+ - EVT_FC_LEFT_UP
+ - EVT_FC_LEFT_DCLICK
+ - EVT_FC_MIDDLE_DOWN
+ - EVT_FC_MIDDLE_UP
+ - EVT_FC_MIDDLE_DCLICK
+ - EVT_FC_RIGHT_DOWN
+ - EVT_FC_RIGHT_UP
+ - EVT_FC_RIGHT_DCLICK
Thanks for all this work!
the event types supported for DrawObject.Bind are:
EVT_FC_LEFT_DOWN
EVT_FC_LEFT_UP
EVT_FC_LEFT_DCLICK
EVT_FC_MIDDLE_DOWN
EVT_FC_MIDDLE_UP
EVT_FC_MIDDLE_DCLICK
EVT_FC_RIGHT_DOWN
EVT_FC_RIGHT_UP
EVT_FC_RIGHT_DCLICK
EVT_FC_ENTER_OBJECT
EVT_FC_LEAVE_OBJECT
The others only apply to the Canvas as a whole, not to individual objects.
+ :param integer `LineWidth`: the width in pixels ???
yes -- pixels is correct.
+ :param integer `Direction`: angle of arrow in degrees, zero is straight
+ up +angle is to the right (theta) ????
correct, but don't need the (theta) -- I think I changed the namem in there at soem point...
def FindClosestPoint(self, XY):
"""
@@ -907,6 +1164,8 @@
This can be used to figure out which point got hit in a mouse
binding callback, for instance. It's a lot faster that using a
lot of separate points.
+
+ :param `XY`: takes a 2-tuple in World coordinates ???
let's try:
:param `XY`: the (x,y) coordinates of the point to look for--takes a 2-tuple or (2,) numpy array in World coordinates
+class Text(TextObjectMixin, DrawObject):
+ """Draws a text object
+
+ ??? do we integrate all this below or ...???
+
yes, I think that all belongs in the constructor docstring.
class ScaledTextBox(TextObjectMixin, DrawObject):
"""
+ ??? what to do with this ??? should it be moved to the appropiate param???
+
This class creates a TextBox object that is scaled when zoomed. It is
placed at the coordinates, x,y.
yes, other than the quick high-level description:
"a multi-line TextBox, which is scaled when zoomed."
The rest should go in the __init__ and/or appropriate methods.
+ :param `Point`: takes a 2-tuple ???
+ :param integer `Size`: size in World pixels ???
opps -- World units.
+ :param `Color`: see :meth:`~lib.floatcanvas.FloatCanvas.DrawObject.SetColor`
+ :param `BackgroundColor`: see :meth:`~lib.floatcanvas.FloatCanvas.DrawObject.SetColor`
+ :param `LineColor`: see :meth:`~lib.floatcanvas.FloatCanvas.DrawObject.SetColor`
+ :param `LineWidth`: see :meth:`~lib.floatcanvas.FloatCanvas.DrawObject.SetLineWidth`
+ :param `Width`: width in pixels or ``None`` ???
yes, this is in pixels (Or None...)
+ :param `PadSize`: padding in pixles or ``None`` ???
This is in World units.
class FloatCanvas(wx.Panel):
"""
- FloatCanvas.py
-
- This is a high level window for drawing maps and anything else in an
- arbitrary coordinate system.
-
+ Do we want this duplicated here???
+
No, that should all be in one place.
+ Default class constructor.
+
+ :param Window `parent`: parent window. Must not be ``None``;
+ :param integer `id`: window identifier. A value of -1 indicates a default value;
+ :param `size`: a tuple or :class:`Size`
+ :param `ProjectionFun`: a custom projection function ???
This allows you to change the transform from world to pixel coordinates. We can point to FloatCanvas.FlatEarthProjection for an example -- though that should really be a class method, or even better, simply a function in the module. There is a tiny bit on info in the error message in FloatCanvas.SetProjectionFun()
(Note: this really should get re-factored to allow more generic projections...)
+ :param string `BackgroundColor`: any value accepted by :class:`Brush`
+ :param `Debug`: activate debug ???
this turns on a smattering of print statements.. not that many really, but we could do more with that.
def FlatEarthProjection(self, CenterPoint):
+ """Set the CenterPoint for FlatEarthProjection ???
+
+ :param `CenterPoint`: takes a 2-tuple, or a (2,)
+ `NumPy <http://www.numpy.org/>`_ array of point coordinates???
+
+ """
let's try:
"""
compute the scaling array for the flat-earth projection
:param `CenterPoint`: center point of viewport (lon, lat) -- the longitude is scaled to the latitude of this point. a 2-tuple, or a (2,) `NumPy <http://www.numpy.org/>`_ array of point coordinates
:returns : a (2,) numpy array that scales world coordinates. This scaling is applied when converting to-from world to pixel coordinates.
"""
def AddToolbarModeButtons(self, tb, Modes):
+ """
+ Add the mode buttons to the tool bar.
+
+ :param ToolBar `tb`: the toolbar instance
+ :param list `Modes`: a list of modes to add ??? what is valid ???
+
+ """
There are the modes defined in GUIMode.py, but the user can define their own, as well.
def Bind(self, Event, CallBackFun):
+ """
+ Bind an event to the DrawObject
+
+ :param `Event`: see below for supported event types ???
I think I covered this in the last email, but I think this is it.
+ - EVT_FC_LEFT_DOWN
+ - EVT_FC_LEFT_UP
+ - EVT_FC_LEFT_DCLICK
+ - EVT_FC_MIDDLE_DOWN
+ - EVT_FC_MIDDLE_UP
+ - EVT_FC_MIDDLE_DCLICK
+ - EVT_FC_RIGHT_DOWN
+ - EVT_FC_RIGHT_UP
+ - EVT_FC_RIGHT_DCLICK
Thanks for all this work!
Chris Barker - NOAA Federal
May 13, 2013, 1:19:25 PM5/13/13
to wxPyth...@googlegroups.com
Werner,
It looks like we crossed paths with our notes...
On Mon, May 13, 2013 at 9:59 AM, werner <wbr...@free.fr> wrote:
I work against this repo:http://svn.wxwidgets.org/svn/wx/wxPython/Phoenix/trunk
OK -- I'll need to give Phoenix a try at some point anyway. But not sure when -- my spare Python time is currently being taken up with teaching a Python class. (note, I a lt of stuff in FloatCanvas that I tell my students NOT to do -- show's what I've learned over the years!
If Robin or you could apply it
I won't have a chance for a while...
Won't have time this week but will get back to this sometimes next week and handle your comments then. There is also quit a bit to be done to FloatCanvas methods, will work on those too.so I'll just comment here:
whenever you can get to it, great!
I don't know if we can UI testing.
I guess there other non UI tests which could still be added, e.g.:
- delete of object
- group stuff
- ?
yup -- all that -- I"d have to go through the methods and see.
I will first continue on the doc and try to get that as close to finish as possible, if someone else wants to attack unittests that would be great.
again, not for a bit, but we'll see.
-Chris
--
werner
May 13, 2013, 1:31:41 PM5/13/13
to wxPyth...@googlegroups.com
On 13/05/2013 19:15, Chris Barker -
NOAA Federal wrote:
On Sat, May 11, 2013 at 3:07 AM, werner <wbr...@free.fr> wrote:
>
> Attached a file with unittests for floatcanvas,
very cool!
Robin, are you using nose or pytest, or just plain old unitttest? (I'm kind of a fan of pytest..)
I don't have imp_unitest or wtc -- Phoenix stuff?
Yeap, imp_unitest is to get unittest2 for <Py2.7 and wtc contains
the unittest.TestCase classes.
so not running, but reading...
> all tests pass for me, but I think they are a bit basic, create a canvas and add an object. I think I got all object types covered, but it would be nice to enhance them to have each object type exercise all parameters and probably some more.
>
yup -- but basic or not, knowing that all the DRawObjects can be created without a crash is a big step up!
Another level would be some of the methods like .Move() and .CalcBoundingBox, etc -- we could check if the geometry of the object was computed properly.
It seems some of this could be done with auto-generated tests -- so we can apply the same test to multiple DrawObject types, for instance. That's a bit klunky with unittest, I think -- one reason I like pytest (or nose)
Of course, the real question is if the object actually gets displayed properly -- but I don't know if we want to go there!
>
> The patch is mainly documentation, plus one real fix to get the tests to pass (wx._gdi.Bitmap and wx._core.Image) and some spacing "corrections".
>
> I have marked things with "???" where I am very unsure about things and/or where I have to go back and clean up.
Will handle your comments when I get back to this.
...
Thanks for all this work!
Your are welcome, I am sure you did a lot more "just" creating FC ;-) .
Werner
Werner
Robin Dunn
May 15, 2013, 1:53:37 PM5/15/13
to wxPyth...@googlegroups.com
Chris Barker - NOAA Federal wrote:
> Robin, are you using nose or pytest, or just plain old unitttest? (I'm
> kind of a fan of pytest..)
Just plain unittest. I wanted to minimize dependencies.
> kind of a fan of pytest..)
What are the features of pytest that made you into a fan? (Just
curious, I haven't looked at it much yet myself.)
--
Robin Dunn
Software Craftsman
http://wxPython.org
Chris Barker - NOAA Federal
May 15, 2013, 2:27:58 PM5/15/13
to wxPyth...@googlegroups.com
On Wed, May 15, 2013 at 10:53 AM, Robin Dunn <ro...@alldunn.com> wrote:
> Chris Barker - NOAA Federal wrote:
>>
>> Robin, are you using nose or pytest, or just plain old unitttest? (I'm
>> kind of a fan of pytest..)
>
> Just plain unittest. I wanted to minimize dependencies.
>
> What are the features of pytest that made you into a fan? (Just curious, I
> haven't looked at it much yet myself.)
* test discovery -- saves a bunch of boiler pate code to actually run the tests
> Chris Barker - NOAA Federal wrote:
>>
>> Robin, are you using nose or pytest, or just plain old unitttest? (I'm
>> kind of a fan of pytest..)
>
> Just plain unittest. I wanted to minimize dependencies.
>
> What are the features of pytest that made you into a fan? (Just curious, I
> haven't looked at it much yet myself.)
* less boiler-plate to write the tests -- unittest makes me feel like
I"m writing Java. The simplest test:
def test_something():
assert something == this
That's it -- you've got a test.
NOTE: nose does those things just as well.
* nice reporting of test failures -- when you have:
assert this == that
and it fails, pytest tells you the values of both this and that,
including values of parameters if this or that is a function call.
* various nice features for parameterized testing, testing for Exceptions, etc.
I saw a talk about it at PyCon a couple years back, and was very
impressed -- it's got a lot of really cool features I haven't even
touched yet.,
Robin Dunn
May 15, 2013, 4:32:38 PM5/15/13
to wxPyth...@googlegroups.com
Chris Barker - NOAA Federal wrote:
> On Wed, May 15, 2013 at 10:53 AM, Robin Dunn<ro...@alldunn.com> wrote:
>> Chris Barker - NOAA Federal wrote:
>>> Robin, are you using nose or pytest, or just plain old unitttest? (I'm
>>> kind of a fan of pytest..)
>> Just plain unittest. I wanted to minimize dependencies.
>>
>> What are the features of pytest that made you into a fan? (Just curious, I
>> haven't looked at it much yet myself.)
>
> * test discovery -- saves a bunch of boiler pate code to actually run the tests
> * less boiler-plate to write the tests -- unittest makes me feel like
> I"m writing Java. The simplest test:
>
> def test_something():
> assert something == this
>
> That's it -- you've got a test.
>
> NOTE: nose does those things just as well.
>
> * nice reporting of test failures -- when you have:
>
> assert this == that
>
> and it fails, pytest tells you the values of both this and that,
> including values of parameters if this or that is a function call.
>
> * various nice features for parameterized testing, testing for Exceptions, etc.
>
> I saw a talk about it at PyCon a couple years back, and was very
> impressed -- it's got a lot of really cool features I haven't even
> touched yet.,
Thanks, that does sound nice.
> On Wed, May 15, 2013 at 10:53 AM, Robin Dunn<ro...@alldunn.com> wrote:
>> Chris Barker - NOAA Federal wrote:
>>> Robin, are you using nose or pytest, or just plain old unitttest? (I'm
>>> kind of a fan of pytest..)
>> Just plain unittest. I wanted to minimize dependencies.
>>
>> What are the features of pytest that made you into a fan? (Just curious, I
>> haven't looked at it much yet myself.)
>
> * test discovery -- saves a bunch of boiler pate code to actually run the tests
> * less boiler-plate to write the tests -- unittest makes me feel like
> I"m writing Java. The simplest test:
>
> def test_something():
> assert something == this
>
> That's it -- you've got a test.
>
> NOTE: nose does those things just as well.
>
> * nice reporting of test failures -- when you have:
>
> assert this == that
>
> and it fails, pytest tells you the values of both this and that,
> including values of parameters if this or that is a function call.
>
> * various nice features for parameterized testing, testing for Exceptions, etc.
>
> I saw a talk about it at PyCon a couple years back, and was very
> impressed -- it's got a lot of really cool features I haven't even
> touched yet.,
Now the most important question, can it run existing unittest.TestCase
style tests so the 560+ test modules we currently have don't need to be
ported? :-)
Chris Barker - NOAA Federal
May 15, 2013, 6:56:09 PM5/15/13
to wxPyth...@googlegroups.com
On Wed, May 15, 2013 at 1:32 PM, Robin Dunn <ro...@alldunn.com> wrote:
> Now the most important question, can it run existing unittest.TestCase style
> tests so the 560+ test modules we currently have don't need to be ported?
yup.
> Now the most important question, can it run existing unittest.TestCase style
> tests so the 560+ test modules we currently have don't need to be ported?
werner
May 29, 2013, 3:50:54 AM5/29/13
to wxPyth...@googlegroups.com
Hi,
Attached a patch which should cover all the notes Chris did and I added
some more documentation.
Please note that the patch includes the "group obj bind" patch I sent a
while a go.
Text in "class ScaledText" suggests that this should get deprecated,
should it just be removed in Phoenix?
Werner
Attached a patch which should cover all the notes Chris did and I added
some more documentation.
Please note that the patch includes the "group obj bind" patch I sent a
while a go.
Text in "class ScaledText" suggests that this should get deprecated,
should it just be removed in Phoenix?
Werner
Chris Barker - NOAA Federal
May 29, 2013, 12:12:10 PM5/29/13
to wxPyth...@googlegroups.com
On Wed, May 29, 2013 at 12:50 AM, werner <wbr...@free.fr> wrote:
> Attached a patch which should cover all the notes Chris did and I added some
> more documentation.
Thanks!
> Attached a patch which should cover all the notes Chris did and I added some
> more documentation.
> Text in "class ScaledText" suggests that this should get deprecated, should
> it just be removed in Phoenix?
right defaults so that it can be a drop-in replacement. And update the
demos.
werner
May 30, 2013, 3:22:50 AM5/30/13
to wxPyth...@googlegroups.com
Hi Chris,
On 29/05/2013 18:12, Chris Barker - NOAA Federal wrote:
...
without surrounding box/line, unless I am missing something I don't
think that can easily be done with the ScaledTextBox, or can it?
If not I will update the documentation for ScaledText.
ScaledTextXXX are sized using "world coordinates", now I have a circle
in which I want to place some text.
Currently I hard code the size, but is there a way I can get it from the
object I want to place the text within.
Werner
On 29/05/2013 18:12, Chris Barker - NOAA Federal wrote:
...
>> Text in "class ScaledText" suggests that this should get deprecated, should
>> it just be removed in Phoenix?
> Maybe -- but we'll need to make sure that the ScaledTextBox has the
> right defaults so that it can be a drop-in replacement. And update the
> demos.
Actually can I take this back;-) , just got a need for scaled text but
>> it just be removed in Phoenix?
> Maybe -- but we'll need to make sure that the ScaledTextBox has the
> right defaults so that it can be a drop-in replacement. And update the
> demos.
without surrounding box/line, unless I am missing something I don't
think that can easily be done with the ScaledTextBox, or can it?
If not I will update the documentation for ScaledText.
ScaledTextXXX are sized using "world coordinates", now I have a circle
in which I want to place some text.
Currently I hard code the size, but is there a way I can get it from the
object I want to place the text within.
Werner
Chris Barker - NOAA Federal
May 30, 2013, 3:20:08 PM5/30/13
to wxPyth...@googlegroups.com
On Thu, May 30, 2013 at 12:22 AM, werner <wbr...@free.fr> wrote:
>>> Text in "class ScaledText" suggests that this should get deprecated,
>>> should
>>> it just be removed in Phoenix?
>>
>> Maybe -- but we'll need to make sure that the ScaledTextBox has the
>> right defaults so that it can be a drop-in replacement. And update the
>> demos.
>
> Actually can I take this back;-) , just got a need for scaled text but
> without surrounding box/line, unless I am missing something I don't think
> that can easily be done with the ScaledTextBox, or can it?
I think you can set the LineStyle to "None", and it should do it.
>>> Text in "class ScaledText" suggests that this should get deprecated,
>>> should
>>> it just be removed in Phoenix?
>>
>> Maybe -- but we'll need to make sure that the ScaledTextBox has the
>> right defaults so that it can be a drop-in replacement. And update the
>> demos.
>
> Actually can I take this back;-) , just got a need for scaled text but
> without surrounding box/line, unless I am missing something I don't think
> that can easily be done with the ScaledTextBox, or can it?
> If not I will update the documentation for ScaledText.
>
> ScaledTextXXX are sized using "world coordinates", now I have a circle in
> which I want to place some text.
>
> Currently I hard code the size, but is there a way I can get it from the
> object I want to place the text within.
But for a Circle, C.XY is the center point, and C.WH is the width and
height (really the radius, in this case, WH is used for compatibility,
tough why it's the radius, and not the diameter, I don't recall!)
I should probably add properties for radius and diameter...
I've enclosed an example of putting a ScaledTextBox on top of a
Circle, placing and sizing it according to the attributes of the
Circle.
(added this to SVN, too)
-Chris
>
> Werner
>
> --
> You received this message because you are subscribed to the Google Groups
> "wxPython-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to wxPython-dev...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
Reply all
Reply to author
Forward
0 new messages