From joskra42.list at gmail.com Tue Feb 5 11:19:13 2019 From: joskra42.list at gmail.com (Joshua Kramer) Date: Tue, 5 Feb 2019 11:19:13 -0500 Subject: [CentralOH] Most "Pythonic" way to accomplish this? Message-ID: Hi Everyone! I'm working on a sort of "test" harness for a project. Essentially, the harness will be able to load a series of tests that will consist of Python classes. I'm trying to figure out the most "Pythonic" way to accomplish this, as well as how to pass data between tests. Is there a better way to express the following? Note that I am targeting Python 2.x with this, though I want it to be compatible with both 2.x and 3.x. Thanks! class myTest: def __init__(self): pass def runTest: pass class fileTest1(myTest): def __init__(self): pass def runTest: check_for_file_1("filename1.txt") class fileTest2(myTest): def __init__(self): pass def runTest: check_for_file_2("filename2.txt") class testDataObject: dataField1 = None dataField2 = None def run_tests(): testList = [] testList.append(fileTest1) testList.append(fileTest2) localObject = testDataObject() for i in testList: # How do I pass localObject between each of these # instantiations of myTest? i.runTest() Thanks! -JK From y2k at y2kbugger.com Tue Feb 5 11:56:58 2019 From: y2k at y2kbugger.com (Zak Kohler) Date: Tue, 5 Feb 2019 11:56:58 -0500 Subject: [CentralOH] Most "Pythonic" way to accomplish this? In-Reply-To: References: Message-ID: pytest - https://docs.pytest.org/en/latest/ the std-lib unittest is a less feature rich, but native solution. On Tue, Feb 5, 2019 at 11:19 AM Joshua Kramer wrote: > > Hi Everyone! > > I'm working on a sort of "test" harness for a project. Essentially, > the harness will be able to load a series of tests that will consist > of Python classes. I'm trying to figure out the most "Pythonic" way > to accomplish this, as well as how to pass data between tests. Is > there a better way to express the following? Note that I am targeting > Python 2.x with this, though I want it to be compatible with both 2.x > and 3.x. Thanks! > > class myTest: > def __init__(self): > pass > def runTest: > pass > > class fileTest1(myTest): > def __init__(self): > pass > def runTest: > check_for_file_1("filename1.txt") > > class fileTest2(myTest): > def __init__(self): > pass > def runTest: > check_for_file_2("filename2.txt") > > class testDataObject: > dataField1 = None > dataField2 = None > > def run_tests(): > testList = [] > testList.append(fileTest1) > testList.append(fileTest2) > > localObject = testDataObject() > > for i in testList: > # How do I pass localObject between each of these > # instantiations of myTest? > i.runTest() > > > > Thanks! > -JK > _______________________________________________ > CentralOH mailing list > CentralOH at python.org > https://mail.python.org/mailman/listinfo/centraloh From y2k at y2kbugger.com Tue Feb 5 11:59:55 2019 From: y2k at y2kbugger.com (Zak Kohler) Date: Tue, 5 Feb 2019 11:59:55 -0500 Subject: [CentralOH] Most "Pythonic" way to accomplish this? In-Reply-To: References: Message-ID: As well as how to pass data between tests. -- in general this is a bad idea, test should not require a specific order to run correctly. To share an common set of data/objects between tests, check out fixtures. https://docs.pytest.org/en/latest/fixture.html#fixture On Tue, Feb 5, 2019 at 11:19 AM Joshua Kramer wrote: > > Hi Everyone! > > I'm working on a sort of "test" harness for a project. Essentially, > the harness will be able to load a series of tests that will consist > of Python classes. I'm trying to figure out the most "Pythonic" way > to accomplish this, as well as how to pass data between tests. Is > there a better way to express the following? Note that I am targeting > Python 2.x with this, though I want it to be compatible with both 2.x > and 3.x. Thanks! > > class myTest: > def __init__(self): > pass > def runTest: > pass > > class fileTest1(myTest): > def __init__(self): > pass > def runTest: > check_for_file_1("filename1.txt") > > class fileTest2(myTest): > def __init__(self): > pass > def runTest: > check_for_file_2("filename2.txt") > > class testDataObject: > dataField1 = None > dataField2 = None > > def run_tests(): > testList = [] > testList.append(fileTest1) > testList.append(fileTest2) > > localObject = testDataObject() > > for i in testList: > # How do I pass localObject between each of these > # instantiations of myTest? > i.runTest() > > > > Thanks! > -JK > _______________________________________________ > CentralOH mailing list > CentralOH at python.org > https://mail.python.org/mailman/listinfo/centraloh From joskra42.list at gmail.com Tue Feb 5 12:13:49 2019 From: joskra42.list at gmail.com (Joshua Kramer) Date: Tue, 5 Feb 2019 12:13:49 -0500 Subject: [CentralOH] Most "Pythonic" way to accomplish this? In-Reply-To: References: Message-ID: Thanks Zak! I should clarify that with this particular question, I am not writing tests for code. For failures, Pytest gives a lot of information about the code, which would not apply in my case. For example, I might want to run some hardware tests. The runTest method in myTest1 object might run a function called "isMotorTooHot()", and if that returns true, then the next test in the list would run "isCoolingValveOpen()", etc. So perhaps we should think of these as "tasks" instead of "tests". From kedlav at gmail.com Tue Feb 5 13:07:31 2019 From: kedlav at gmail.com (Max) Date: Tue, 5 Feb 2019 13:07:31 -0500 Subject: [CentralOH] Most "Pythonic" way to accomplish this? In-Reply-To: References: Message-ID: Generally speaking, it's strongly discouraged to structure tests in this way where you have conditional logic baked into the test. Instead, you'd want to setup individual tests covering scenarios. Base State: Motor running Test 1: 1.) Call function 2.) mock return of temperature below 'too hot' 3.) assert that the correct behavior has occurred. Test 2: 1.) Call function 2.) mock return of temperature below 'too hot' 3.) assert that the isCoolingValveOpen function was called Test 3: Unit tests to cover isCoolingValveOpen does what it is supposed to do. On Tue, Feb 5, 2019 at 12:14 PM Joshua Kramer wrote: > Thanks Zak! I should clarify that with this particular question, I am > not writing tests for code. For failures, Pytest gives a lot of > information about the code, which would not apply in my case. For > example, I might want to run some hardware tests. The runTest method > in myTest1 object might run a function called "isMotorTooHot()", and > if that returns true, then the next test in the list would run > "isCoolingValveOpen()", etc. So perhaps we should think of these as > "tasks" instead of "tests". > _______________________________________________ > CentralOH mailing list > CentralOH at python.org > https://mail.python.org/mailman/listinfo/centraloh > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joskra42.list at gmail.com Tue Feb 5 14:01:03 2019 From: joskra42.list at gmail.com (Joshua Kramer) Date: Tue, 5 Feb 2019 14:01:03 -0500 Subject: [CentralOH] Most "Pythonic" way to accomplish this? In-Reply-To: References: Message-ID: Hi Max, I'm not sure I'm understanding you correctly. It seems that the example you provided will test that the function "isMotorTooHot()" works as intended- a unit test on the function isMotorTooHot. That's not my intent. For this particular example, I want to call a function that will determine if the motor is too hot. If the motor IS too hot, I then want to call a function that will check to see if the cooling valve is open Unit testing to determine whether or not the various functions (isMotorTooHot, isCoolingValveOpen, etc) return correct values based on physical attributes is not within the purview of this specific example- that will be handled elsewhere. My goal is to write a framework that I can use to run arbitrary sets of tests for specific conditions in the environment, not within a class or other bit of Python code. On Tue, Feb 5, 2019 at 1:08 PM Max wrote: > > Generally speaking, it's strongly discouraged to structure tests in this way where you have conditional logic baked into the test. Instead, you'd want to setup individual tests covering scenarios. > > Base State: Motor running > Test 1: > 1.) Call function > 2.) mock return of temperature below 'too hot' > 3.) assert that the correct behavior has occurred. > > Test 2: > 1.) Call function > 2.) mock return of temperature below 'too hot' > 3.) assert that the isCoolingValveOpen function was called > > Test 3: > Unit tests to cover isCoolingValveOpen does what it is supposed to do. > > On Tue, Feb 5, 2019 at 12:14 PM Joshua Kramer wrote: >> >> Thanks Zak! I should clarify that with this particular question, I am >> not writing tests for code. For failures, Pytest gives a lot of >> information about the code, which would not apply in my case. For >> example, I might want to run some hardware tests. The runTest method >> in myTest1 object might run a function called "isMotorTooHot()", and >> if that returns true, then the next test in the list would run >> "isCoolingValveOpen()", etc. So perhaps we should think of these as >> "tasks" instead of "tests". >> _______________________________________________ >> CentralOH mailing list >> CentralOH at python.org >> https://mail.python.org/mailman/listinfo/centraloh > > _______________________________________________ > CentralOH mailing list > CentralOH at python.org > https://mail.python.org/mailman/listinfo/centraloh From kedlav at gmail.com Tue Feb 5 14:32:52 2019 From: kedlav at gmail.com (Max) Date: Tue, 5 Feb 2019 14:32:52 -0500 Subject: [CentralOH] Most "Pythonic" way to accomplish this? In-Reply-To: References: Message-ID: Let's say you have logic like: if isMotorToHot: checkCoolingValveOpen You can easily mock the isMotorToHot function to return True or False (assuming it returns a bool) using the mock library. Then, you can check to see if the function has been called. Ideally, you want a test for Both of these come really easy through mock and pytest without any dependency on the hardware. That way, you're isolating your test to just see the flow through the conditional logic. Structuring this way allows you to skip calling the actual device code (as you just need to see if the fxn is called) and run a separate pytest suite for things that directly interact with the device and may or may not be god-awful slow due to the mechanical nature of real life. On Tue, Feb 5, 2019 at 2:01 PM Joshua Kramer wrote: > Hi Max, I'm not sure I'm understanding you correctly. It seems that > the example you provided will test that the function "isMotorTooHot()" > works as intended- a unit test on the function isMotorTooHot. That's > not my intent. For this particular example, I want to call a function > that will determine if the motor is too hot. If the motor IS too hot, > I then want to call a function that will check to see if the cooling > valve is open > > Unit testing to determine whether or not the various functions > (isMotorTooHot, isCoolingValveOpen, etc) return correct values based > on physical attributes is not within the purview of this specific > example- that will be handled elsewhere. My goal is to write a > framework that I can use to run arbitrary sets of tests for specific > conditions in the environment, not within a class or other bit of > Python code. > > On Tue, Feb 5, 2019 at 1:08 PM Max wrote: > > > > Generally speaking, it's strongly discouraged to structure tests in this > way where you have conditional logic baked into the test. Instead, you'd > want to setup individual tests covering scenarios. > > > > Base State: Motor running > > Test 1: > > 1.) Call function > > 2.) mock return of temperature below 'too hot' > > 3.) assert that the correct behavior has occurred. > > > > Test 2: > > 1.) Call function > > 2.) mock return of temperature below 'too hot' > > 3.) assert that the isCoolingValveOpen function was called > > > > Test 3: > > Unit tests to cover isCoolingValveOpen does what it is supposed to do. > > > > On Tue, Feb 5, 2019 at 12:14 PM Joshua Kramer > wrote: > >> > >> Thanks Zak! I should clarify that with this particular question, I am > >> not writing tests for code. For failures, Pytest gives a lot of > >> information about the code, which would not apply in my case. For > >> example, I might want to run some hardware tests. The runTest method > >> in myTest1 object might run a function called "isMotorTooHot()", and > >> if that returns true, then the next test in the list would run > >> "isCoolingValveOpen()", etc. So perhaps we should think of these as > >> "tasks" instead of "tests". > >> _______________________________________________ > >> CentralOH mailing list > >> CentralOH at python.org > >> https://mail.python.org/mailman/listinfo/centraloh > > > > _______________________________________________ > > CentralOH mailing list > > CentralOH at python.org > > https://mail.python.org/mailman/listinfo/centraloh > _______________________________________________ > CentralOH mailing list > CentralOH at python.org > https://mail.python.org/mailman/listinfo/centraloh > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deeppunster at gmail.com Tue Feb 5 23:51:48 2019 From: deeppunster at gmail.com (Travis Risner) Date: Tue, 05 Feb 2019 23:51:48 -0500 Subject: [CentralOH] Most "Pythonic" way to accomplish this? In-Reply-To: References: Message-ID: <5C5A67E4.5040004@gmail.com> Hi Joshua, If I understand your intent, you are not interested in mocking anything. Instead, you want to periodically run some tasks on something external to Python. Given that assumption, if I were wanting to accomplish this, I would look for a framework or library that would let me do the following: * Schedule running the task in a way that is external to the task. * Let the task report the results in a stratified way (e.g. like HTML response code) so that I could specify -- external to the task -- what subsequent action to take. * Allow the tasks to run either asynchronously or as a series of sequential tasks if that is necessary. Maybe another way of thinking about this it to let the data drive the activity rather than baking the scheduling, reporting, and/or subsequent action into the code. I would pull all of the things that might change out of the code so frequency of testing, action to take based on results of the test, etc. can be easily managed with a GUI or an easily modified configuration file or table. HTH, Travis Max wrote: > Let's say you have logic like: > > if isMotorToHot: > checkCoolingValveOpen > > You can easily mock the isMotorToHot function to return True or False > (assuming it returns a bool) using the mock library. Then, you can > check to see if the function has been called. Ideally, you want a test > for Both of these come really easy through mock and pytest without any > dependency on the hardware. That way, you're isolating your test to > just see the flow through the conditional logic. Structuring this way > allows you to skip calling the actual device code (as you just need to > see if the fxn is called) and run a separate pytest suite for things > that directly interact with the device and may or may not be god-awful > slow due to the mechanical nature of real life. > > On Tue, Feb 5, 2019 at 2:01 PM Joshua Kramer > wrote: > > Hi Max, I'm not sure I'm understanding you correctly. It seems that > the example you provided will test that the function "isMotorTooHot()" > works as intended- a unit test on the function isMotorTooHot. That's > not my intent. For this particular example, I want to call a function > that will determine if the motor is too hot. If the motor IS too hot, > I then want to call a function that will check to see if the cooling > valve is open > > Unit testing to determine whether or not the various functions > (isMotorTooHot, isCoolingValveOpen, etc) return correct values based > on physical attributes is not within the purview of this specific > example- that will be handled elsewhere. My goal is to write a > framework that I can use to run arbitrary sets of tests for specific > conditions in the environment, not within a class or other bit of > Python code. > > On Tue, Feb 5, 2019 at 1:08 PM Max > wrote: > > > > Generally speaking, it's strongly discouraged to structure tests > in this way where you have conditional logic baked into the test. > Instead, you'd want to setup individual tests covering scenarios. > > > > Base State: Motor running > > Test 1: > > 1.) Call function > > 2.) mock return of temperature below 'too hot' > > 3.) assert that the correct behavior has occurred. > > > > Test 2: > > 1.) Call function > > 2.) mock return of temperature below 'too hot' > > 3.) assert that the isCoolingValveOpen function was called > > > > Test 3: > > Unit tests to cover isCoolingValveOpen does what it is supposed > to do. > > > > On Tue, Feb 5, 2019 at 12:14 PM Joshua Kramer > > wrote: > >> > >> Thanks Zak! I should clarify that with this particular > question, I am > >> not writing tests for code. For failures, Pytest gives a lot of > >> information about the code, which would not apply in my case. For > >> example, I might want to run some hardware tests. The runTest > method > >> in myTest1 object might run a function called "isMotorTooHot()", and > >> if that returns true, then the next test in the list would run > >> "isCoolingValveOpen()", etc. So perhaps we should think of these as > >> "tasks" instead of "tests". > >> _______________________________________________ > >> CentralOH mailing list > >> CentralOH at python.org > >> https://mail.python.org/mailman/listinfo/centraloh > > > > _______________________________________________ > > CentralOH mailing list > > CentralOH at python.org > > https://mail.python.org/mailman/listinfo/centraloh > _______________________________________________ > CentralOH mailing list > CentralOH at python.org > https://mail.python.org/mailman/listinfo/centraloh > > _______________________________________________ > CentralOH mailing list > CentralOH at python.org > https://mail.python.org/mailman/listinfo/centraloh -- Sent by Travis Risner From pybokeh at gmail.com Wed Feb 6 05:42:29 2019 From: pybokeh at gmail.com (pybokeh) Date: Wed, 6 Feb 2019 05:42:29 -0500 Subject: [CentralOH] Most "Pythonic" way to accomplish this? In-Reply-To: References: Message-ID: Joshua, maybe Travis us right. If you're interested in a task scheduling framework, there's Apache Airflow ( https://github.com/apache/airflow/blob/master/README.md). It is a bit of a heavy framework. If you don't need to necessarily schedule tasks at certain times or intervals, but just execute tasks based on execution of other tasks, there's Luigi ( https://github.com/spotify/luigi/blob/master/README.rst). I use Luigi at work for running data processing tasks, but tasks can be any Python function. Here's a relatively short video on it: https://m.youtube.com/watch?v=TYtHzvys33A If you want a lighter framework, there's bonobo ( https://www.bonobo-project.org). Even though it is geared for data processing tasks or ETL, I believe it can be used for executing regular Python functions also. On Tue, Feb 5, 2019, 2:01 PM Joshua Kramer Hi Max, I'm not sure I'm understanding you correctly. It seems that > the example you provided will test that the function "isMotorTooHot()" > works as intended- a unit test on the function isMotorTooHot. That's > not my intent. For this particular example, I want to call a function > that will determine if the motor is too hot. If the motor IS too hot, > I then want to call a function that will check to see if the cooling > valve is open > > Unit testing to determine whether or not the various functions > (isMotorTooHot, isCoolingValveOpen, etc) return correct values based > on physical attributes is not within the purview of this specific > example- that will be handled elsewhere. My goal is to write a > framework that I can use to run arbitrary sets of tests for specific > conditions in the environment, not within a class or other bit of > Python code. > > On Tue, Feb 5, 2019 at 1:08 PM Max wrote: > > > > Generally speaking, it's strongly discouraged to structure tests in this > way where you have conditional logic baked into the test. Instead, you'd > want to setup individual tests covering scenarios. > > > > Base State: Motor running > > Test 1: > > 1.) Call function > > 2.) mock return of temperature below 'too hot' > > 3.) assert that the correct behavior has occurred. > > > > Test 2: > > 1.) Call function > > 2.) mock return of temperature below 'too hot' > > 3.) assert that the isCoolingValveOpen function was called > > > > Test 3: > > Unit tests to cover isCoolingValveOpen does what it is supposed to do. > > > > On Tue, Feb 5, 2019 at 12:14 PM Joshua Kramer > wrote: > >> > >> Thanks Zak! I should clarify that with this particular question, I am > >> not writing tests for code. For failures, Pytest gives a lot of > >> information about the code, which would not apply in my case. For > >> example, I might want to run some hardware tests. The runTest method > >> in myTest1 object might run a function called "isMotorTooHot()", and > >> if that returns true, then the next test in the list would run > >> "isCoolingValveOpen()", etc. So perhaps we should think of these as > >> "tasks" instead of "tests". > >> _______________________________________________ > >> CentralOH mailing list > >> CentralOH at python.org > >> https://mail.python.org/mailman/listinfo/centraloh > > > > _______________________________________________ > > CentralOH mailing list > > CentralOH at python.org > > https://mail.python.org/mailman/listinfo/centraloh > _______________________________________________ > CentralOH mailing list > CentralOH at python.org > https://mail.python.org/mailman/listinfo/centraloh > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at intellovations.com Tue Feb 19 11:21:01 2019 From: eric at intellovations.com (Eric Floehr) Date: Tue, 19 Feb 2019 11:21:01 -0500 Subject: [CentralOH] February Monthly Meeting this coming Monday, February 25 Message-ID: COhPy's monthly meeting is this coming Monday. RSVP here: https://www.meetup.com/Central-Ohio-Python-Users-Group/events/259093081 This month Jessica Harper will be presenting "Having fun with Languages". We will be actively coding in this meet up with old languages from the 60s and new languages. She encourages people to try and brush up on LOL CODE. There are a few competitions with prizes as well. This won?t be a set down and suck it in meetup?.we are going to have fun :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From zach at mailup.net Tue Feb 19 18:38:23 2019 From: zach at mailup.net (Zach Villers) Date: Tue, 19 Feb 2019 18:38:23 -0500 Subject: [CentralOH] Jetbrains Webinar on async with Michael Kennedy Tommorow Noon Eastern In-Reply-To: References: Message-ID: <400b0a1c-fef9-4f07-a36e-a8cb396af73e@www.fastmail.com> Link to RSVP here; https://info.jetbrains.com/pycharm-webinar-february-2019.html Zach Villers zach at mailup.net From koshea1 at cscc.edu Tue Feb 26 11:59:18 2019 From: koshea1 at cscc.edu (Katie O'Shea) Date: Tue, 26 Feb 2019 16:59:18 +0000 Subject: [CentralOH] Searching for Python instructors for non-credit intro class Message-ID: Hi All - I work at Columbus State and manage our non-credit IT certificate programs with various employers around Columbus. (https://www.cscc.edu/for-business/it-workforce-certificates.shtml) Our certificate programs are in Software Development, Data Analytics and Cybersecurity, and are intended for individuals who may or may not have IT experience but are looking to reskill. The program participants are typically selected by an employer and are part of a cohort taking the courses together. As part of the Data Analytics and the Cybersecurity programs we offer an introductory Python class. The course is 8 weeks long and typically runs from 5-7:30 one night a week. The next Python course begins Thursday, March 21 and we recently learned our anticipated instructor won't be available so we are actively looking. If anyone on this list has an interest in teaching introductory Python (in March or beyond) I would be happy to share more information. Please contact me at koshea1 at cscc.edu. Thanks, Katie -------------- next part -------------- An HTML attachment was scrubbed... URL: