Classic OOP in Python
Hello Python community. I come from a classic background in what refers to OOP. Mostly Java and PHP (> 5.3). I'm used to abstract classes, interfaces, access modifiers and so on. Don't get me wrong. I know that despite the differences Python is fully object oriented. My point is, do you know any book or resource that explains in deep the pythonic way of doing OOP? For example, I'm gonna try to develop a modest application from ground up using TDD. If it had been done in Java for instance, I would made extensive use of interfaces to define the boundaries of my system. How would I do something like that in Python? Many thanks! -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
El miércoles, 17 de junio de 2015, 21:44:51 (UTC+2), Ned Batchelder escribió: > On Wednesday, June 17, 2015 at 3:21:32 PM UTC-4, Jason P. wrote: > > Hello Python community. > > > > I come from a classic background in what refers to OOP. Mostly Java and PHP > > (> 5.3). I'm used to abstract classes, interfaces, access modifiers and so > > on. > > > > Don't get me wrong. I know that despite the differences Python is fully > > object oriented. My point is, do you know any book or resource that > > explains in deep the pythonic way of doing OOP? > > > > For example, I'm gonna try to develop a modest application from ground up > > using TDD. If it had been done in Java for instance, I would made extensive > > use of interfaces to define the boundaries of my system. How would I do > > something like that in Python? > > > > > > Many thanks! > > What other languages do with interfaces, Python does with duck-typing. You > can build something like interfaces in Python, but many people don't bother. > > I don't know if your project will be web-based, but here is an entire book > about developing Python web sites with a TDD approach: > > http://www.obeythetestinggoat.com/ > > (Don't mind the unusual domain name, it's a bit of an inside joke...) > > TDD and interfaces are separate concepts, and I'm not sure they even > intersect. TDD is about writing tests as a way to design the best system, > and putting testing at the center of your development workflow. It works > great with Python even without interfaces. > > --Ned. I'm aware of duck typing. The point in using interfaces is to be explicit about the boundaries of a system. Quite a red "Growing Object-Oriented Software, Guided by Tests", by the way. In fact interfaces are key components in the style of building software they propose, in good company with TDD. Thx! -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
El miércoles, 17 de junio de 2015, 21:44:51 (UTC+2), Ned Batchelder escribió: > On Wednesday, June 17, 2015 at 3:21:32 PM UTC-4, Jason P. wrote: > > Hello Python community. > > > > I come from a classic background in what refers to OOP. Mostly Java and PHP > > (> 5.3). I'm used to abstract classes, interfaces, access modifiers and so > > on. > > > > Don't get me wrong. I know that despite the differences Python is fully > > object oriented. My point is, do you know any book or resource that > > explains in deep the pythonic way of doing OOP? > > > > For example, I'm gonna try to develop a modest application from ground up > > using TDD. If it had been done in Java for instance, I would made extensive > > use of interfaces to define the boundaries of my system. How would I do > > something like that in Python? > > > > > > Many thanks! > > What other languages do with interfaces, Python does with duck-typing. You > can build something like interfaces in Python, but many people don't bother. > > I don't know if your project will be web-based, but here is an entire book > about developing Python web sites with a TDD approach: > > http://www.obeythetestinggoat.com/ > > (Don't mind the unusual domain name, it's a bit of an inside joke...) > > TDD and interfaces are separate concepts, and I'm not sure they even > intersect. TDD is about writing tests as a way to design the best system, > and putting testing at the center of your development workflow. It works > great with Python even without interfaces. > > --Ned. I forgot to mention that the book you recommend seems to be a good starting point ;) -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
El miércoles, 17 de junio de 2015, 22:39:31 (UTC+2), Marko Rauhamaa escribió:
> Ned Batchelder :
>
> > TDD is about writing tests as a way to design the best system, and
> > putting testing at the center of your development workflow. It works
> > great with Python even without interfaces.
>
> I wonder how great it really is. Testing is important, that's for sure,
> but to make it a dogmatic starting point of development is not that
> convincing.
>
> The way it was explained to me was that in TDD you actually don't write
> code to any requirements or design: you simply do the least to pass the
> tests. Thus, say you need to write a program that inputs a string and
> outputs the same string surrounded by parentheses (the requirement), the
> starting point might be this test case:
>
>- run the program
>- give it the word "hello" as input
>- check that the program prints out "(hello)"
>
> The right TDD thing would be to satisfy the test with this program:
>
>input()
>print("(hello)")
>
> That *ought* to be the first version of the program until further test
> cases are added that invalidate it.
>
>
> Another interesting ism I have read about is the idea that the starting
> point of any software project should be the user manual. The developers
> should then go and build the product that fits the manual.
>
>
> Marko
The refactor phase is key in TDD (red-green-refactor). Again, GOOS is an
advisable source of knowledge in this matter.
--
https://mail.python.org/mailman/listinfo/python-list
Noob in Python. Problem with fairly simple test case
Hi all!
I'm working in a little Python exercise with testing since the beginning. So
far I'm with my first end to end test (not even finished yet) trying to:
1) Launch a development web server linked to a demo app that just returns
'Hello World!'
2) Make a GET request successfully
I can't understand very well what's happening. It seems that the main thread
gets blocked listening to the web server. My intent was to spawn another
process for the server independent of the test. Obviously I'm doing something
wrong. I've made several guesses commenting pieces of code (tearDown method for
example) but I didn't manage to solve the problem(s).
I'm running the test through PyCharm. Python version = 3.4.3
Here it's the code:
test_forecast_end_to_end.py
===
import unittest
from tests.end_to_end.forecastserver import ForecastServer
import src.forecast.webservice as webservice
import requests
class TestForecastEndToEnd(unittest.TestCase):
def setUp(self):
# Start the forecast server
self.server = ForecastServer()
self.server.start(webservice.app)
def tearDown(self):
# Stop the forecast server
self.server.stop()
def test_webservice_receives_a_request(self):
response = requests.get('http://localhost:8000')
print(response.text)
if __name__ == '__main__':
unittest.main()
forecastserver.py
=
from wsgiref.simple_server import make_server
import multiprocessing
class ForecastServer:
def __init__(self):
self._httpd_process = None
def start(self, webservice):
if not self._httpd_process:
httpd = make_server('localhost', 8000, webservice)
self._httpd_process = multiprocessing.Process(
target=httpd.serve_forever)
self._httpd_process.start()
def stop(self):
if self._httpd_process:
self._httpd_process.join()
self._httpd_process.terminate()
del self._httpd_process
webservice.py
=
def app(environ, start_response):
status = '200 OK'
headers = [('Content-type', 'text/plain')]
start_response(status, headers)
return ['Hello World!']
--
https://mail.python.org/mailman/listinfo/python-list
Re: Noob in Python. Problem with fairly simple test case
El miércoles, 15 de julio de 2015, 14:12:08 (UTC+2), Chris Angelico escribió: > On Wed, Jul 15, 2015 at 9:44 PM, Jason P. wrote: > > I can't understand very well what's happening. It seems that the main > > thread gets blocked listening to the web server. My intent was to spawn > > another process for the server independent of the test. Obviously I'm doing > > something wrong. I've made several guesses commenting pieces of code > > (tearDown method for example) but I didn't manage to solve the problem(s). > > > > When you find yourself making guesses to try to figure out what's > going on, here are two general tips: > > 1) Cut out as many pieces as you can. Test one small thing at a time. > 2) If In Doubt, Print It Out! Stick print() calls into the code at key > places, displaying the values of parameters or the results of > intermediate calculations - or just saying "Hi, I'm still here and I'm > running!". > > For #1, I would recommend first just trying to get the web service > going. Can you connect (using an external program) on port 8000 and > receive a text/plain HTTP response saying "Hello World!"? Never mind > about the test for the moment. > > And for #2, judicious placement of console output will help you figure > out things you're not sure about. For instance, you're suspecting that > the main thread is getting blocked handling the web server. Easy way > to check: > > def setUp(self): > # Start the forecast server > self.server = ForecastServer() > self.server.start(webservice.app) > > Just before you construct the server, print something out. After > you've constructed it but before you call start(), print something > out. And after starting it, print something out. Then run the program. > If you see the first line and no other, then it's blocking during the > construction. Other deductions I'm sure you can figure out. > > One small point: Probe even things that you think are trivial. In the > above example, I cannot see any reason why constructing > ForecastServer() could possibly block, because its init does nothing > but set a flag. But you can get surprised by things sometimes - maybe > the problem is actually that you're not running the code you think you > are, but there's some other ForecastServer kicking in, and it's > synchronous rather than subprocess-based. > > End-to-end testing is all very well, but when something goes wrong, > the key is to break the program down into smaller parts. Otherwise, > all you have is "it doesn't work", which is one of the most useless > error reports ever. If someone comes to python-list saying "it doesn't > work", we'll be asking him/her to give a lot more details; if your > aunt asks you for help printing out a document because "it doesn't > work", you'll probably have to go over and watch her attempt it; and > it's the same with your test cases - you make them tell you more > details. > > Hope that helps! The techniques I'm offering are completely > problem-independent, and even language-independent. IIDPIO debugging > works in anything that gives you a console, which is pretty much > everything - maybe it won't be print() but logging.debug(), but the > same technique works. > > ChrisA Thanks for your comments Chris. I've come back to the problem today after a few days on trip. Fortunately someone in other mailing list pointed me that the join method was hanging the main thread. Without this inconvenience I can focus on the exercise's main goal. Despite the impression that surely I gave, I'm quite familiar with programming and general bug hunting rules. The problem is that I'm inexperienced with Python and the subtle details of multiple threads ;) Thanks! -- https://mail.python.org/mailman/listinfo/python-list
