Re: [Tutor] understanding code testing

[Aaron Myatt via Tutor]

My favourite book on testing. It is a pretty thorough walk through of
building a django app that helps you get a feel for the TDD work flow and
red, green, refactor cycle. A rather more practical and real world
applicable introduction to TDD,  in my opinion.

On 16 Apr 2017 12:59 a.m., "Rafael Knuth"  wrote:

> can anyone point me to good learning resources on this subject?
> (python 3)
> ___
> Tutor maillist  -  Tutor@python.org
> To unsubscribe or change subscription options:
> https://mail.python.org/mailman/listinfo/tutor
>
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] understanding code testing

[Alan Gauld via Tutor]

On 16/04/17 03:18, Aaron Myatt via Tutor wrote:
> My favourite book on testing. It is a pretty thorough walk through of
> building a django app that helps you get a feel for the TDD work flow and
> red, green, refactor cycle. A rather more practical and real world
> applicable introduction to TDD,  in my opinion.

But which book is it?


-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] understanding code testing

[Mats Wichmann]

On 04/15/2017 08:33 AM, Rafael Knuth wrote:
> can anyone point me to good learning resources on this subject?
> (python 3)
> ___
> Tutor maillist  -  Tutor@python.org
> To unsubscribe or change subscription options:
> https://mail.python.org/mailman/listinfo/tutor
> 

There is a lot of information on the PyTest website - the
talks/tutorials in particular might be interesting.

https://docs.pytest.org/en/latest/


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Tutor] Can a virtual environment be renamed?

[Jim]

My system python is 2.7.12 so I created a virtual environment using venu 
to run 3.5.2. I put it in /home/jfb/EVs/env. Now I would like to try 3.6 
and put it in env36. Is it possible to change env to env35 for 3.5.2 
without breaking things?


Thanks, Jim

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Can a virtual environment be renamed?

[Chris Warrick]

On 16 April 2017 at 16:45, Jim  wrote:
> My system python is 2.7.12 so I created a virtual environment using venu to
> run 3.5.2. I put it in /home/jfb/EVs/env. Now I would like to try 3.6 and
> put it in env36. Is it possible to change env to env35 for 3.5.2 without
> breaking things?

No. You need to delete your existing virtualenv and create a new one.
You can just use `pip freeze > requirements.txt` in the old one and
run `pip install -r requirements.txt` in the new one to ”move” all the
packages you had.


-- 
Chris Warrick 
PGP: 5EAAEA16
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Do not understand code snippet from "26.8. test — Regression tests package for Python"

[boB Stepp]

On Sat, Apr 15, 2017 at 6:31 PM, Alan Gauld via Tutor  wrote:
> On 16/04/17 00:17, boB Stepp wrote:
>
>> --
>> #!/usr/bin/env python3
>>
>> def mySuperWhammyFunction(any_input):
>> return any_input
>
> This is a simple function, its not bound to an object

I did not name this function.  I think that if the docs' example meant
it to be a method, they would have named it, "mySuperWhammyMethod".

>>
>> import unittest
>>
>> class TestFuncAcceptsSequencesMixin:
>>
>> func = mySuperWhammyFunction
>>
>> def test_func(self):
>> self.func(self.arg)
>
> This is calling self.function which implies a method.
>
> Convert your function to a method and it should work.

I did this and it indeed works.  But how do I use this technique to
unittest the given function?  I am just not seeing how to do it with
this with this mixin approach, and I have yet to study mixins, though
apparently I have just now started!

In the modified program (per your suggestion) to test a method (I
still need to know how to make this test the original *function*!), I
now have:

--
class SuperWhammy:
def mySuperWhammyFunction(self, any_input):
return any_input

import unittest

class TestFuncAcceptsSequencesMixin:

obj = SuperWhammy
func = obj.mySuperWhammyFunction

def test_func(self):
f = self.func(self.arg)
self.assertEqual(f, self.arg)
print(f)

class AcceptLists(TestFuncAcceptsSequencesMixin, unittest.TestCase):
arg = [1, 2, 3]

class AcceptStrings(TestFuncAcceptsSequencesMixin, unittest.TestCase):
arg = 'abc'

class AcceptTuples(TestFuncAcceptsSequencesMixin, unittest.TestCase):
arg = (1, 2, 3)

if __name__ == '__main__':
unittest.main()
--

This gives me the results:

> python -m unittest -v test_super.py
test_func (test_super.AcceptLists) ... [1, 2, 3]
ok
test_func (test_super.AcceptStrings) ... abc
ok
test_func (test_super.AcceptTuples) ... (1, 2, 3)
ok

--
Ran 3 tests in 0.000s

Questions:

1)  I did not notice it until this AM, but I used (as above) "obj =
SuperWhammy".  Normally I would write this as "obj = SuperWhammy()"
with parentheses.  But I see that both work.  Are the parentheses
unneeded when creating an object instance if there are no
initialization arguments needed?

2)  The big question:  What is the program flow for this program?  I
am not seeing the order of execution here.  How is the unittest module
handling the execution of this?  The ending comment in the docs'
example cited reads:

"When using this pattern, remember that all classes that inherit from
unittest.TestCase are run as tests. The Mixin class in the example
above does not have any data and so can’t be run by itself, thus it
does not inherit from unittest.TestCase."

This suggests to me that unittest "uses" the bottom three classes, but
even though each of the three inherits from the class
TestFuncAcceptsSequenceMixin, those classes don't have any methods
that they call on that class, so how does its code get run?  I suspect
that the mixin's concepts is where I am stumbling.  I have yet to find
a reference that is making things clear to me, though I will continue
searching and reading.

-- 
boB
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Can a virtual environment be renamed?

[Jim]

On 04/16/2017 10:10 AM, Chris Warrick wrote:

On 16 April 2017 at 16:45, Jim  wrote:

My system python is 2.7.12 so I created a virtual environment using venu to
run 3.5.2. I put it in /home/jfb/EVs/env. Now I would like to try 3.6 and
put it in env36. Is it possible to change env to env35 for 3.5.2 without
breaking things?


No. You need to delete your existing virtualenv and create a new one.
You can just use `pip freeze > requirements.txt` in the old one and
run `pip install -r requirements.txt` in the new one to ”move” all the
packages you had.




Thanks Chris. I thought that would be the answer but wanted to check 
before I spent a lot of time trying to do something that was not possible.


Virtual environments tend to confuse me. My system is Mint 18.1 with 
2.7.12 & 3.5.2 installed. So I would have to download a tar file of 3.6, 
then build it and then use it's version of venv to create a virtual 
environment to try 3.6. Is that correct?


Thanks,  Jim

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Can a virtual environment be renamed?

[Chris Warrick]

On 16 April 2017 at 18:16, Jim  wrote:
> On 04/16/2017 10:10 AM, Chris Warrick wrote:
>>
>> On 16 April 2017 at 16:45, Jim  wrote:
>>>
>>> My system python is 2.7.12 so I created a virtual environment using venu
>>> to
>>> run 3.5.2. I put it in /home/jfb/EVs/env. Now I would like to try 3.6 and
>>> put it in env36. Is it possible to change env to env35 for 3.5.2 without
>>> breaking things?
>>
>>
>> No. You need to delete your existing virtualenv and create a new one.
>> You can just use `pip freeze > requirements.txt` in the old one and
>> run `pip install -r requirements.txt` in the new one to ”move” all the
>> packages you had.
>>
>>
>
> Thanks Chris. I thought that would be the answer but wanted to check before
> I spent a lot of time trying to do something that was not possible.
>
> Virtual environments tend to confuse me. My system is Mint 18.1 with 2.7.12
> & 3.5.2 installed. So I would have to download a tar file of 3.6, then build
> it and then use it's version of venv to create a virtual environment to try
> 3.6. Is that correct?

Yes, you need to install the appropriate interpreter first, and
likewise a virtualenv won’t work if you uninstall an
interpreter/upgrade it to a new minor version*. You might not need to
use the source tarball if
https://launchpad.net/~fkrull/+archive/ubuntu/deadsnakes works on Mint
(and if you do use tarballs, make sure to install somewhere in /opt or
whatever not to make a mess — it’s easy to break your OS if you’re not
careful)

* eg. 3.5 → 3.6. Won’t ever happen on Mint or other “friendly”
distros, unless you do a dist-upgrade. Happens pretty often on
rolling-release distros or macOS with homebrew.

-- 
Chris Warrick 
PGP: 5EAAEA16
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Do not understand code snippet from "26.8. test — Regression tests package for Python"

[Alan Gauld via Tutor]

On 16/04/17 16:21, boB Stepp wrote:

> I did this and it indeed works.  But how do I use this technique to
> unittest the given function?  I am just not seeing how to do it with
> this with this mixin approach, and I have yet to study mixins, though
> apparently I have just now started!

I'm not familiar with the mixin approach so don;t know what
they intend but...

> --
> class SuperWhammy:
> def mySuperWhammyFunction(self, any_input):
> return any_input
> 
> import unittest
> 
> class TestFuncAcceptsSequencesMixin:
> 
> obj = SuperWhammy
> func = obj.mySuperWhammyFunction

Note this is a class attribute not an instance one
so you could attach a "normal" function and call it
via the class.

> def test_func(self):
> f = self.func(self.arg)

f = TestFuncAcceptsSequencesMixin.func(self.args)

> self.assertEqual(f, self.arg)
> print(f)

But I've no idea if that's what the author intended...

I tried it on your original code and it seemed to work OK.

> 1)  I did not notice it until this AM, but I used (as above) "obj =
> SuperWhammy".  Normally I would write this as "obj = SuperWhammy()"
> with parentheses.  But I see that both work.  Are the parentheses
> unneeded when creating an object instance if there are no
> initialization arguments needed?

No, you are not creating an instance but a reference to the class.
So when you assigned the function you were in effect doing

func = SuperWhammy.mySuperWhammyFunction

Which of course works fine.

> 2)  The big question:  What is the program flow for this program?  I
> am not seeing the order of execution here.  How is the unittest module
> handling the execution of this?  The ending comment in the docs'
> example cited reads:

I'll let a unittest expert comment on that fully.

So far as I understand it, the unittest framework
just calls all the test_xxx methods of all classes
that inherit from TestCase. And because all three
test classes inherit the mixin and its test_func()
method they all execute that method but each providing
their own version of args.

Exactly how that magic is accomplished I leave to
the framework authors! ;-)


> "When using this pattern, remember that all classes that inherit from
> unittest.TestCase are run as tests. The Mixin class in the example
> above does not have any data and so can’t be run by itself, thus it
> does not inherit from unittest.TestCase."
> 
> This suggests to me that unittest "uses" the bottom three classes, but
> even though each of the three inherits from the class
> TestFuncAcceptsSequenceMixin, those classes don't have any methods
> that they call on that class, so how does its code get run?  

They inherit the test_fujnc() method from the mixin.
And the TestCase looks for  methods called test_xxx
and runs them. (It could be as simple as doing a dir(self),
I really don't know.)

> that the mixin's concepts is where I am stumbling.  I have yet to find
> a reference that is making things clear to me, though I will continue
> searching and reading.

Mixins are conceptually very simple, just small classes
expressing a capability that you inherit along with your
other super classes. There is nothing intrinsically special
about them, its more about the concept than the implementation.
(Some languages use mixins a lot and have dedicated support
for them such as not having them inherit from object to avoid
the dreaded MI diamond patterns or other similar tricks.) The
introduction of interfaces into languages like Java and C#
have made mixins less common.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Python 3.6 Multiply the elements of a 2D Array by the elements of a 1D Aeeay

[giacomo . boffi]

"Stephen P. Molnar"  writes:

> I have an list generated by:   s = np.linspace(start,finish,points)
>
> and an array D:
>
>  [ 0.  2.0598013.60937686  3.32591826  2.81569212]
>  [ 2.0598010.  4.71452879  4.45776445  4.00467382]
>  [ 3.60937686  4.71452879  0.  5.66500917  5.26602175]
>  [ 3.32591826  4.45776445  5.66500917  0.  5.02324896]
>  [ 2.81569212  4.00467382  5.26602175  5.02324896  0.]
>
> Now I can multiply the Array by one element of the list:
>
> s2 = 1.100334448160535050  (The first non-zero list element.)
> s2_D = s2*np.array(D)
>
> which results in:
>
>  [ 0.  2.26647 3.97152169  3.65962243  3.09820303]
>  [ 2.26647 0.  5.18755844  4.90503178  4.40648056]
>  [ 3.97152169  5.18755844  0.  6.23340474  5.79438514]
>  [ 3.65962243  4.90503178  6.23340474  0.  5.52725387]
>  [ 3.09820303  4.40648056  5.79438514  5.52725387  0.]
>
> I checked this, rather laboriously, in a spreadsheet.
>
> However, what I want to do is multiply each element ob D by each
> element of s and sum all of the products.

if I understand what you want to do,

  R_ij = sum_k(D_ij s_k)

you can do it in a number of ways, say D has shape(i, j) and s has shape(k)

Possibility 1

c = np.outer(D, s) # c has shape (i*j, k) as outer flattens its arguments 
c = sum(c, 1)  # c has shape (i*j) because se summed over 2nd index
c.reshape(D.shape) # c has the shape of D, i.e., (i, j)

Possibility 2

# https://docs.scipy.org/doc/numpy/reference/generated/numpy.einsum.html
stackoverflow.com/questions/26089893/understanding-numpys-einsum
c = np.einsum('ij,k -> ij', D, s)


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Do not understand code snippet from "26.8. test — Regression tests package for Python"

[Martin A. Brown]

Greetings boB,

>2)  The big question:  What is the program flow for this program?  I
>am not seeing the order of execution here.  How is the unittest module
>handling the execution of this? 

This is a very good question and one that was (at one time) 
inobvious to me, as well.

When you write a program, you usually have a clear notion of where 
the program will begin and then can follow its execution path (from 
"if __name__ == '__main__'") through your functions, class 
instantiations and method calls.  This is the execution structure of 
your program.  (I'd imagine you have used print and/or logging to 
debug program flow, as well)

Testing flow is different.

The sequence of test execution has nothing to do with your program 
structure.  This is utterly intentional.

[ background / digression ] By breaking down a complex program into 
smaller testable pieces, you can have more assurance that your 
program is doing exactly what you intend.  Since you are breaking 
the program into smaller pieces, those pieces can (and should) be 
runnable and tested without requiring any of the other pieces.

Usually (almost always) tests are run in isolation.  This allows you 
to control exactly the arguments, environment and conditions of each 
test.

You may know most of the above already, but I repeat it because 
these facts help explain why testing tools work as they do...
[ end digression ]

Now, to the unittest module.

(Please note, I'm not an expert on unittest internals, so I may get 
a detail or two wrong.  Nonetheless, I hope that my answer will help 
you orient yourself around what's happening.)

When you run a tool to collect your tests and execute them, the path 
through your pieces of code under test has no connection whatsoever 
to process flow through your program.

The basic flow looks like this:

  * find the test cases / test suites you have written
  * run each of the tests independently, i.e. isolated conditions
  * report on the success/failure of each test case, test suite and 
the whole batch

See below for more detail of the mechanics inside the unittest 
module.  What happens when you execute your testing suite?  Let's 
say you run:

  $ python -m unittest

(Unless there is customization of TestLoader TestSuite and/or 
TestRunner) the following sequence occurs:

  1. the Python interpreter starts up

  2. Python loads the unittest module and passes control to unittest

  3. unittest.main creates an instance of unittest.TestLoader [0]

  4. unittest.TestLoader scans the filesystem, collecting a list of 
 tests to run from:

   - any test suites subclassed from unittest.TestSuite [1]
   - any test cases subclassed unittest.TestCase [2]

  5. unittest.TestLoader imports anything it found and returns the 
 list of tests to the main testing program loop

  6. the main loop passes the tests to the unittest.TextTestRunner [3],
 which executes each test and (probably) produces some output 
 telling you either that your hard work has paid off or that 
 something is still wrong

Your next question is why do the mixins work?  And how do they work?

I'll make a few observations:

  - [on unittest] the unit testing tools use classes because it's a 
natural way to accommodate the goal of reproducibly setting up 
arguments and/or an environment for each test (note that each 
TestCase can have its own setUp() and tearDown() methods; this 
allows isolation)

  - [on unittest] each test collected by the TestLoader can be any 
Python class (as long as it is also derived from 
unittest.TestCase)

  - [on your classes] your classes use a multiple inheritance 
model, deriving from TestFuncAcceptsSequencesMixin; when 
instantiated, they'll have all of the expected TestCase methods
and the method called 'test_func'

In more detail, you have created three different classes, each of 
which is derived from unittest.TestCase (I'm showing just the 
signatures):

  class AcceptLists(TestFuncAcceptsSequencesMixin, unittest.TestCase):
  class AcceptStrings(TestFuncAcceptsSequencesMixin, unittest.TestCase): 
  class AcceptTuples(TestFuncAcceptsSequencesMixin, unittest.TestCase):

Here's what's happening:

  - TestLoader finds the files that contains the above classes (probably
named 'test_something.py')

  - Testloader imports the file 'test_something.py'; this defines your
classes: AcceptLists, AcceptStrings and AcceptTuples (or will 
produce a traceback if the code does not import; try breaking 
your code and you should see that the import of your test code 
fails during the TestLoader phase)

  - TestLoader appends the now-defined classes: AcceptLists,
AcceptStrings and AcceptTuples to the list of tests

  - control passes back to main and then to TestRunner

  - for each unittest.TestCase in the list of tests, TestRunner will:

- create an instance T from the defined class

- for each method name starting with 'test_

Re: [Tutor] Python 3.6 Multiply the elements of a 2D Array by the elements of a 1D Aeeay

[giacomo . boffi]

giacomo.bo...@gmail.com writes:

I throw two errors in my answer, see the inline corrections

> Possibility 1
>
> c = np.outer(D, s) # c has shape (i*j, k) as outer flattens its arguments 
> c = sum(c, 1)  # c has shape (i*j) because se summed over 2nd index

  c = np.sum(c, 1)   # c has shape (i*j) because se summed over 2nd index
  
> c.reshape(D.shape) # c has the shape of D, i.e., (i, j)
>
> Possibility 2
>
> # https://docs.scipy.org/doc/numpy/reference/generated/numpy.einsum.html
> stackoverflow.com/questions/26089893/understanding-numpys-einsum

  # http://stackoverflow.com/questions/26089893/understanding-numpys-einsum

> c = np.einsum('ij,k -> ij', D, s)

in particular `c = sum(...)` instead of `c = np.sum(...)` is a nasty
error because `sum` is a builtin and the error message one gets could be
misleading

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Can a virtual environment be renamed?

[Mats Wichmann]

On 04/16/2017 10:16 AM, Jim wrote:
> On 04/16/2017 10:10 AM, Chris Warrick wrote:
>> On 16 April 2017 at 16:45, Jim  wrote:
>>> My system python is 2.7.12 so I created a virtual environment using
>>> venu to
>>> run 3.5.2. I put it in /home/jfb/EVs/env. Now I would like to try 3.6
>>> and
>>> put it in env36. Is it possible to change env to env35 for 3.5.2 without
>>> breaking things?
>>
>> No. You need to delete your existing virtualenv and create a new one.
>> You can just use `pip freeze > requirements.txt` in the old one and
>> run `pip install -r requirements.txt` in the new one to ”move” all the
>> packages you had.
>>
>>
> 
> Thanks Chris. I thought that would be the answer but wanted to check
> before I spent a lot of time trying to do something that was not possible.
> 
> Virtual environments tend to confuse me. My system is Mint 18.1 with
> 2.7.12 & 3.5.2 installed. So I would have to download a tar file of 3.6,
> then build it and then use it's version of venv to create a virtual
> environment to try 3.6. Is that correct?
> 
> Thanks,  Jim

It doesn't need to be terribly complicated, something called pyenv can
manage the install for you (yes, it will build it if needed).

pyenv install --list

to show what's available to install

pyenv install 3.6.0

to install a copy

If you set up the shell helpers, pyenv will let you create the
virtualenv and launch it:

pyenv virtualenv 3.6.0 test-3.6.0
pyenv activate test-3.6.0

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Python 3.6 Multiply the elements of a 2D Array by the elements of a 1D Aeeay

[Sergio Rojas]

On 04/14/2017 04:21 AM, Peter Otten wrote:
> Stephen P. Molnar wrote:
>
>> However, what I want to do is multiply each element ob D by each element
>> of s and sum all of the products.
>
> If you *really* want this:
>
> sum_of_all_products = s.sum() * D.sum()
>
> example:
>
> s = [a b c]
>
> D = [[a1 a2]
> [a3 a4]]
>
> a*a1 + a*a2 + a*a3 + a*a4 = a * D.sum()
>
> d := D.sum()
> a*d + b*d + c*d = s.sum() * d
>
> Even if that's what you want you should heed Steven's advice.
>

Nice example on "analyze before computing". Nevertheless,
A lazy man's approach to life might  go  using numpy ufunc.outer
 [ https://docs.scipy.org/doc/numpy/reference/generated/numpy.ufunc.outer.html ]


In [1]: import numpy as np

In [2]: from sympy import symbols

In [3]: x1, y1, z1, x2, y2, z2, x3, y3, z3 = symbols('x1 y1 z1 x2 y2 z2 x3 y3 z3
   ...: ')

In [4]: x=np.array([[x1,y1,z1], [x2,y2,z2], [x3,y3,z3]])

In [5]: z=np.array([z1,z2,z3])

In [6]: print(np.multiply.outer(z,x))
[[[x1*z1 y1*z1 z1**2]
  [x2*z1 y2*z1 z1*z2]
  [x3*z1 y3*z1 z1*z3]]

 [[x1*z2 y1*z2 z1*z2]
  [x2*z2 y2*z2 z2**2]
  [x3*z2 y3*z2 z2*z3]]

 [[x1*z3 y1*z3 z1*z3]
  [x2*z3 y2*z3 z2*z3]
  [x3*z3 y3*z3 z3**2]]]

In [7]: np.multiply.outer(z,x).sum()
Out[7]: x1*z1 + x1*z2 + x1*z3 + x2*z1 + x2*z2 + x2*z3 + x3*z1 + x3*z2 + x3*z3 + 
y1*z1 + y1*z2 + y1*z3 + y2*z1 + y2*z2 + y2*z3 + y3*z1 + y3*z2 + y3*z3 + z1**2 + 
2*z1*z2 + 2*z1*z3 + z2**2 + 2*z2*z3 + z3**2

In [8]: 

Sergio
https://www.packtpub.com/big-data-and-business-intelligence/numerical-and-scientific-computing-scipy-video
https://github.com/rojassergio/Learning-Scipy
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] understanding code testing

[boB Stepp]

On Sat, Apr 15, 2017 at 9:33 AM, Rafael Knuth  wrote:
> can anyone point me to good learning resources on this subject?
> (python 3)

I have been liking "Testing Python -- Applying Unit Testing, TDD, BDD,
and Acceptance Testing" by David Sale, c. 2014.  If you are into
developing web stuff, then you might like "Test-Driven Development
with Python -- Obey the Testing Goat:  Using Django, Selenium, and
JavaScript" by Harry J. W. Percival, c. 2014.



-- 
boB
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Do not understand code snippet from "26.8. test — Regression tests package for Python"

[boB Stepp]

Thank you very much Martin; you filled in a lot of details.  I had an
overall understanding of what unittest does, but you have now enhanced
that understanding substantially.  I'm still iffy on how the mixin
class gets its test method called when this class does not subclass
from unittest.TestCase, but I think I may have an idea now on how it
is happening.  Let's get to that part of your response.

On Sun, Apr 16, 2017 at 3:59 PM, Martin A. Brown  wrote:

[snip]

> Your next question is why do the mixins work?  And how do they work?
>
> I'll make a few observations:
>
>   - [on unittest] the unit testing tools use classes because it's a
> natural way to accommodate the goal of reproducibly setting up
> arguments and/or an environment for each test (note that each
> TestCase can have its own setUp() and tearDown() methods; this
> allows isolation)
>
>   - [on unittest] each test collected by the TestLoader can be any
> Python class (as long as it is also derived from
> unittest.TestCase)
>
>   - [on your classes] your classes use a multiple inheritance
> model, deriving from TestFuncAcceptsSequencesMixin; when
> instantiated, they'll have all of the expected TestCase methods
> and the method called 'test_func'

It is here that I am struggling.  If the mixin class does not inherit
from unittest.TestCase, then how is test_func ever seen?

> In more detail, you have created three different classes, each of
> which is derived from unittest.TestCase (I'm showing just the
> signatures):
>
>   class AcceptLists(TestFuncAcceptsSequencesMixin, unittest.TestCase):
>   class AcceptStrings(TestFuncAcceptsSequencesMixin, unittest.TestCase):
>   class AcceptTuples(TestFuncAcceptsSequencesMixin, unittest.TestCase):
>
> Here's what's happening:
>
>   - TestLoader finds the files that contains the above classes (probably
> named 'test_something.py')
>
>   - Testloader imports the file 'test_something.py'; this defines your
> classes: AcceptLists, AcceptStrings and AcceptTuples (or will
> produce a traceback if the code does not import; try breaking
> your code and you should see that the import of your test code
> fails during the TestLoader phase)
>
>   - TestLoader appends the now-defined classes: AcceptLists,
> AcceptStrings and AcceptTuples to the list of tests
>
>   - control passes back to main and then to TestRunner
>
>   - for each unittest.TestCase in the list of tests, TestRunner will:
>
> - create an instance T from the defined class

This answers one important thing I was wondering about:  How do the
classes AcceptLists, AcceptStrings, and AcceptTuples get instantiated?
 Apparently the unittest machinery does this for me.

> - for each method name starting with 'test_' (you have only
>   'test_func') TestRunner will:

And here is my precise sticking point:  How does the TestRunner find
test_func?  The classes it has collected and instantiated
(AcceptLists, AcceptStrings and AcceptTuples) do not themselves call
and make use of the test_func method they inherit from the mixin
class.

>   - execute the T.setUp() method if it exists
>
>   - TestRunner will execute the method 'test_func'

The only thing that makes sense to me is that the TestRunner follows
the MRO of the inherited classes and checks for any test_xxx methods
that might exist in those superclasses.  Is this correct or do I have
a conceptual misunderstanding?

>   - collect the success / failure and any outputs
>
>   - report on the success / failure
>
>   - produce some final summary output and set the exit code
> accordingly (os.EX_OK means success, anything else is failure)
>

[snip]

> I hope my long-winded explanation amkes that a bit clearer.

More clarity has been achieved, but I am not fully there yet!

Thanks!

-- 
boB
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Do not understand code snippet from "26.8. test — Regression tests package for Python"

[boB Stepp]

OK, between Alan and Martin I think that I see how to make the code
snippet actually test a *function* as the snippet seems to suggest.
Recollect that my original question(s) started:

On Sat, Apr 15, 2017 at 6:17 PM, boB Stepp  wrote:
> In the section
>
> https://docs.python.org/3/library/test.html#writing-unit-tests-for-the-test-package
>
> I have been trying to make sense of the given pointer and code snippet:
>
> 
> Try to maximize code reuse. On occasion, tests will vary by something
> as small as what type of input is used. Minimize code duplication by
> subclassing a basic test class with a class that specifies the input:
>
> class TestFuncAcceptsSequencesMixin:
>
> func = mySuperWhammyFunction
>
> def test_func(self):
> self.func(self.arg)
>
> class AcceptLists(TestFuncAcceptsSequencesMixin, unittest.TestCase):
> arg = [1, 2, 3]
>
> class AcceptStrings(TestFuncAcceptsSequencesMixin, unittest.TestCase):
> arg = 'abc'
>
> class AcceptTuples(TestFuncAcceptsSequencesMixin, unittest.TestCase):
> arg = (1, 2, 3)
>
> When using this pattern, remember that all classes that inherit from
> unittest.TestCase are run as tests. The Mixin class in the example
> above does not have any data and so can’t be run by itself, thus it
> does not inherit from unittest.TestCase.
> 

The snippet as supplied will not run.  "mySuperWhammyFunction" is not
defined anywhere.  Additionally, the code to start the unittest
machinery going was not included (But to be fair, it was just
discussed above this snippet.).  In my original effort I tried to stay
as true as possible to the code snippet in the docs and only added the
"missing" elements I just mentioned.  However, I think the docs are
misleading with this line:

func = mySuperWhammyFunciton

and this line:

self.func(self.arg)

I asked myself, how am I now testing functions with unittest?  I've
been doing it for a few months now.  What I would do in the context of
this Mixin approach would be:

def mySuperWhammyFunction(any_input):
return any_input

import unittest

class TestFuncAcceptsSequencesMixin:

def test_func(self):
f = mySuperWhammyFunction(self.arg)# What need is there
for the class variable func?
self.assertEqual(f, self.arg)  # Just call and assign
the function being tested directly!
print(f)

class AcceptLists(TestFuncAcceptsSequencesMixin, unittest.TestCase):
arg = [1, 2, 3]

class AcceptStrings(TestFuncAcceptsSequencesMixin, unittest.TestCase):
arg = 'abc'

class AcceptTuples(TestFuncAcceptsSequencesMixin, unittest.TestCase):
arg = (1, 2, 3)

if __name__ == '__main__':
unittest.main()

This works fine and produces this output:

> python -m unittest -v test_super.py
test_func (test_super.AcceptLists) ... [1, 2, 3]
ok
test_func (test_super.AcceptStrings) ... abc
ok
test_func (test_super.AcceptTuples) ... (1, 2, 3)
ok

--
Ran 3 tests in 0.002s

OK

Am I missing anything?  If not, then why did the code snippet use the
(I believe to be misleading.) class variable approach with "func =
mySuperWhammyFunction" and "self.func(self.arg)"?

boB
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Do not understand code snippet from "26.8. test — Regression tests package for Python"

[Alan Gauld via Tutor]

On 17/04/17 05:01, boB Stepp wrote:

> Am I missing anything?  If not, then why did the code snippet use the
> (I believe to be misleading.) class variable approach with "func =
> mySuperWhammyFunction" and "self.func(self.arg)"?

I suspect it was a slightly broken attempt at reuse in that
you can assign other functions to the class variable func.
In your code the function is hard coded into the test_func()
method. The original code (apart from using self.func) allowed
the mixin func attribute to be reset to different functions.

But I'm guessing at the authors intent, it may just have
been over-engineering...

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Do not understand code snippet from "26.8. test — Regression tests package for Python"

[Mats Wichmann]

On 04/16/2017 10:01 PM, boB Stepp wrote:
> OK, between Alan and Martin I think that I see how to make the code
> snippet actually test a *function* as the snippet seems to suggest.
> Recollect that my original question(s) started:


You got me thinking as well, as I don't much care for unittest, at least
partly because it forces you to use classes even when it doesn't feel
all that natural.

So here's a vaguely practical example of applying the same pattern using
pytest - that is, if you're going to test a function several different
ways, can you use just one test function instead of writing multiples.

First let's write the function to test: it tries to reverse its
argument, which should be something that can be iterated over, using
fancy list slicing.  To show it's working there is also code to try it
out if it is called as a program (as opposed to as a module).

=== reverser.py ==
def slicerev(collection):
return collection[::-1]

if __name__ == "__main__":
print slicerev([1,2,3,4])
print slicerev((1,2,3,4))
print slicerev('abcd')
===

Now write a test for this function, naming it, by convention,
test_{funcname}.py. (if it's named this way pytest can find it
automatically but it's not mandatory, you can give the name of the test
file as an argument).

Import pytest because we need the definition of the fixture decorator;
and import the function we're going to be testing, since it is, after
all, in a different file.

Since what we're factoring here is supplying different sets of data,
decorate a function "slicedata" which will return the data, turning it
into a pytest fixture (there's plenty of information on pytest fixtures
so won't repeat here); supply pairs of values where one value is the
data to call the function with and the other is the expected result of
calling the function under test.

The actual test function should be pretty straightforward.

=== test_slicerev.py ===
import pytest

from reverser import slicerev

@pytest.fixture(params=[
([1,2,3,4], [4,3,2,1]),
((1,2,3,4), (4,3,2,1)),
('abcd','edcba')
])
def slicedata(request):
return request.param

def test_slicerev(slicedata):
input, expected = slicedata
output = slicerev(input)
assert output == expected
===

Run the tests with "py.test test_slicerev.py"

Note the "expected" data for the string type is intentionally incorrect
so you should see an error with some explanatory output.

(you'll probably have to install pytest, since it's not in the standard
library; pytest can run all the unittest style tests too though).
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] How do we create a GUI to run a simple calculation program in Python?

[Palm Tree]

On 16 Apr 2017 10:01, "Palm Tree"  wrote:

Sorry for late reply.

We usually organise python challenges.

Once we organise a gui calculator challenge.

You can view the submissions on my blog here:
https://abdurrahmaanjanhangeer.wordpress.com/gui-py-
calculator-challenge-19-1-17/

On 16 Apr 2017 09:50, "Alex Kleider"  wrote:

> On 2017-04-15 01:04, Alan Gauld via Tutor wrote:
>
>
>
>> Finally, if you can find a copy of my recent book "Python Projects"
>> there is a rolling project within that which demonstrates how
>> the same logic code can be used to build a CLI, a GUI and a
>> Web app. [ In fact it goes even further by demonstrating how
>> to break an app into 3 tiers - data, logic and UI - which
>> is industry best practice, but usually overkill for small
>> projects.]
>>
>
> Thanks, Alan, for the guidance.  As it happens, I have a copy of your
> Python Projects" book- time to get it off the shelf and have a closer look!
> Alex
> ___
> Tutor maillist  -  Tutor@python.org
> To unsubscribe or change subscription options:
> https://mail.python.org/mailman/listinfo/tutor
>
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Tutor] Need help with code

[Tyler Seacrist]

Hello,


I need to draw a stack diagram for print_n called with s = 'Hello' and n=2 and 
am unsure of how to do so.


Thanks,

Tyler
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] bracket issue

[Palm Tree]

-- Forwarded message --
From: "Palm Tree" 
Date: 16 Apr 2017 10:07
Subject: Re: [Tutor] bracket issue
To: "Peter Otten" <__pete...@web.de>
Cc:

Ok thanks for the answers. Perfect.

Just to clarify why i wanted recursion was that well coming to compiler
theory, i created a python-based language called newB

it allows you to define your own keywords but don't abuse

like you can configure if to cheese

cheese x == 4:

coming to recursion well i currently use eval() so everything ok i don't
have to worry about brackets but i want to write my own parser. a top down
parser for expressions.

you can also view the lang here:
http://wp.me/p7UB6x-oV

thanks for the answers once more

On 15 Apr 2017 18:46, "Peter Otten" <__pete...@web.de> wrote:

> Palm Tree wrote:
>
> > hi all. i'm trying to write a simple program. i'm using python 3.4
> >
> > let us say i have
> >
> > s="2*3+3(8-4(5+6+9))+2+3+3(4/4)"
> >
> > i want to find expression enclosed in brackets.
> >
> > i want outputs to be like:
> > (8-4(5+6+9))
> > (5+6+9)
> > (4/4)
> > note : i'd like an answer involving recursion if possible
>
> No recursion, but a stack managed manually:
>
> >>> s = "2*3+3(8-4(5+6+9))+2+3+3(4/4)"
> >>> stack = []
> >>> for i, c in enumerate(s):
> ... if c == "(":
> ... stack.append(i)
> ... elif c == ")":
> ... print(s[stack.pop():i+1])
> ...
> (5+6+9)
> (8-4(5+6+9))
> (4/4)
>
> The order is determined by the closing parenthesis, you could sort if you
> don't want that.
>
> I did not find a convincing translation using recursion, but I'll give one
> anyway:
>
> def find_closing(s):
> i = c = None
> pairs = enumerate(s)
> def step(start=None):
> nonlocal i, c
> for i, c in pairs:
> if c == "(":
> step(i)
> elif c == ")":
> if start is not None:
> print(s[start:i+1])
> return
> step()
>
> ___
> Tutor maillist  -  Tutor@python.org
> To unsubscribe or change subscription options:
> https://mail.python.org/mailman/listinfo/tutor
>
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor