Re: Classic OOP in Python
On Thursday, 18 June 2015 12:21:29 UTC+1, Jason P. wrote: > > 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! Late to the party, but I have added a package `jute` to PyPI which provides interface checking closer to the model used in Java (and other compiled OO languages). See https://github.com/jongiddy/jute -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
Ah, turns out there was an entry. I updated it. Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
On 19/06/2015 00:01, Laura Creighton wrote: In a message of Thu, 18 Jun 2015 11:50:28 +0100, Mark Lawrence writes: Throw in http://clonedigger.sourceforge.net/ as well and you've a really awesome combination. Mark Lawrence I didn't know about that one. Hey thank you, Mark. Looks great. It needs its own entry in https://wiki.python.org/moin/PythonTestingToolsTaxonomy You add it, or me? Laura Thanks all the same but I'll leave it to you, as I suspect I'd be my usual combination of headless chicken and bull in a china shop if let loose on a wiki :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- 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
On Thu, Jun 18, 2015 at 1:03 PM, Fabien fabien.mauss...@gmail.com wrote: On 06/17/2015 11:16 PM, sohcahto...@gmail.com wrote: You don't need interfaces with Python. Duck typing makes that all possible. Yes, but I also like interfaces (or in python: mimicked interfaces with NotImplementedError) for their clarity and documentation purposes. Would you consider the following kind of program unpythonic? class MovingObject(object): Great doc about what a moving object is def move(self): Great doc about move raise NotImplementedError() class Dog(MovingObject): def move(self): print Dog is moving class Car(MovingObject): def move(self): print Car is moving (Disclaimer: I learned OOP with Java) I think this is what abstract base classes are for in Python. -- 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
Todd toddr...@gmail.com: On Thu, Jun 18, 2015 at 1:03 PM, Fabien fabien.mauss...@gmail.com wrote: Would you consider the following kind of program unpythonic? class MovingObject(object): Great doc about what a moving object is def move(self): Great doc about move raise NotImplementedError() class Dog(MovingObject): def move(self): print Dog is moving class Car(MovingObject): def move(self): print Car is moving (Disclaimer: I learned OOP with Java) I think this is what abstract base classes are for in Python. And they can be ok as long as you're not making them into a habit. Marko -- 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 n...@nedbatchelder.com: 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
Re: Classic OOP in Python
On Thursday, June 18, 2015 at 7:21:29 AM UTC-4, Jason P. wrote: 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. Yes, that book uses interfaces, because that book uses Java. Different languages offer different tools. You can make interfaces in Python, but you don't need to. They aren't enforced by Python, so you aren't gaining much other than documentation from them, so why not just use documentation? Abstract classes provide another tool. They can insist that you provide implementations of abstract methods. In my experience, it is easy to get to a point where you are struggling to satisfy your simple-minded abstract classes, rather than writing the code that you know you need to solve your actual problem. As Chris just mentioned elsewhere in this thread, you have to be very careful how you define your abstract classes. I've worked in Java projects where I had to provide 10 dummy implementations of methods I knew I wasn't going to need, just because the interface insisted they had to exist. The Python culture is to document your expectations, and write enough tests to verify that your code does what it claims to do. You are already planning on a TDD flow, so you will have plenty of tests. Try doing without interfaces or abstract classes. See how it goes. It's the Python way. :) --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
On Thu, Jun 18, 2015 at 9:03 PM, Fabien fabien.mauss...@gmail.com wrote: Would you consider the following kind of program unpythonic? class MovingObject(object): Great doc about what a moving object is def move(self): Great doc about move raise NotImplementedError() class Dog(MovingObject): def move(self): print Dog is moving class Car(MovingObject): def move(self): print Car is moving (Disclaimer: I learned OOP with Java) Now try extending the concept to two, three, or four such interfaces. Files can be moved, opened, copied, and unlinked. Should they share any sort of interface with dogs, boxes, handwriting, and railway carriages? It's much better to simply define the attributes of each object separately; most non-trivial cases don't involve simple methods with no additional arguments, and the chances of an incompatibility (or worse, a forced compatibility) go up. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
On 06/17/2015 11:16 PM, sohcahto...@gmail.com wrote: You don't need interfaces with Python. Duck typing makes that all possible. Yes, but I also like interfaces (or in python: mimicked interfaces with NotImplementedError) for their clarity and documentation purposes. Would you consider the following kind of program unpythonic? class MovingObject(object): Great doc about what a moving object is def move(self): Great doc about move raise NotImplementedError() class Dog(MovingObject): def move(self): print Dog is moving class Car(MovingObject): def move(self): print Car is moving (Disclaimer: I learned OOP with Java) Fabien -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
python -m doctest application.py And from there, I would build up extra doc tests An extra doc test that fails #!/usr/bin/env python NewsGroup comp.lang.python Subject .. Classic OOP in Python Date . 2015-06-17 Post_By .. Steven D'Aprano Edit_By .. Stanley C. Kitching def bracket( s ) : Return string s bracketed in parentheses. bracket( Hello ) '(Hello)' bracket( Yo Mama is a Perl Monkey ) '(Yo Mama is a Java Monkey') return (%s) % s -- Stanley C. Kitching Human Being Phoenix, Arizona -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
In a message of Thu, 18 Jun 2015 11:50:28 +0100, Mark Lawrence writes: Throw in http://clonedigger.sourceforge.net/ as well and you've a really awesome combination. Mark Lawrence I didn't know about that one. Hey thank you, Mark. Looks great. It needs its own entry in https://wiki.python.org/moin/PythonTestingToolsTaxonomy You add it, or me? Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
On 17/06/2015 23:33, sohcahto...@gmail.com wrote: I had a Java class where we had to learn TDD, and that's the way TDD was taught to us, and I hated it. We watched a video of this guy explaining TDD with a hat that was red on the front and green on the back. It involved writing a simple failing unit test, then write code to fix it, then refactor the tests and/or code. I do not think it is important that the test fails before writing the code, but for sure it is really wise to ensure every test fails at least once. If I wrote a test and it has never failed before, then I always change something in the test itself, in order to have an expected failure. And sometimes the expected failures make me better understand the behavior of the code. As an in-class exercise, we had to write an implementation of Conway's Game of Life. I threw TDD out the window and just wrote the damn program in under 15 minutes, then another 10 minutes to write unit tests that tested every possible code branch and several invalid inputs. Meanwhile, the people doing TDD the right way didn't even have a complete program after over an hour. The brand of TTD we were taught would end up multiplying development time by at least a factor of 3, and by the time you were done, at least 75% of the tests you had written will have been removed due to rampant refactoring. IMO, that kind of TTD is an utter waste of time. I think TDD helps a lot to design the code to be testable as much as possible. I believe good and experienced programmers could think in advance the way to write testable code, without be driven by tests. However, I also think that the bigger part of programmers, as me, do not have this ability. That's the case TDD comes in handy helping us to write testable code. In case of bug fixing, I think also experienced and good programmers that do not believe in TDD should always write the tests in advance, for instance because: * it is really the better way to understand the problem and point to it * chances are that you will not write a test after fixing the bug, i.e. because you may have other priorities, so you will miss a regression test -- Marco Buttu INAF-Osservatorio Astronomico di Cagliari Via della Scienza n. 5, 09047 Selargius (CA) Phone: 070 711 80 217 Email: mbu...@oa-cagliari.inaf.it -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
On 17/06/2015 23:33, Laura Creighton wrote: In a message of Wed, 17 Jun 2015 14:14:34 -0700, Ned Batchelder writes: TDD is supposed to make you brave, not cowards, and it's Ned's most excellent tool http://nedbatchelder.com/code/coverage/ that I recommend to TDD dogmatic cowards. Even if you don't want to use TTD, you will enjoy Ned's tool. It's GREAT. Thank you, Ned. Laura Throw in http://clonedigger.sourceforge.net/ as well and you've a really awesome combination. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
On Wed, Jun 17, 2015 at 2:21 PM, Jason P. suscrici...@gmail.com wrote: 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? Maybe start here: http://stackoverflow.com/questions/2124190/how-do-i-implement-interfaces-in-python and see if abstract base classes will be sufficient. (I wouldn't know. I've never used Java or PHP.) More generally, you might try search the web for interfaces in python. The above just seemed to be the most relevant response to me. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
In a message of Wed, 17 Jun 2015 14:33:43 -0700, sohcahto...@gmail.com writes: I had a Java class where we had to learn TDD, and that's the way TDD was taught to us, and I hated it. We watched a video of this guy explaining TDD with a hat that was red on the front and green on the back. It involved writing a simple failing unit test, then write code to fix it, then refactor the tests and/or code. As an in-class exercise, we had to write an implementation of Conway's Game of Life. I threw TDD out the window and just wrote the damn program in under 15 minutes, then another 10 minutes to write unit tests that tested every possible code branch and several invalid inputs. Meanwhile, the people doing TDD the right way didn't even have a complete program after over an hour. The brand of TTD we were taught would end up multiplying development time by at least a factor of 3, and by the time you were done, at least 75% of the tests you had written will have been removed due to rampant refactoring. IMO, that kind of TTD is an utter waste of time. I'd hate that too. But that's not the TDD I know, or teach. Please don't write off TDD as a result of this experience. Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
In a message of Wed, 17 Jun 2015 14:14:34 -0700, Ned Batchelder writes: The true TDD acolytes advocate a very idiosyncratic workflow, it's true. I don't do this, but I also don't consider myself a TDD person. I value tests a great deal, and put a lot of effort into them, but I don't write trivial functions to get my tests to pass and then go back to change them. Grrr. I am a true TDD acolyte. And I don't do that either. But people whose opinion I value do advocate that, and it's possible that in time I will understand their methods and use them myself. Stranger things have happened... --Ned. Seriously? Oh you humble man. I have convinced a huge number of people who used to have that sort of dogma that the reason they advocated such baby steps is that they didn't have a good coverage tool. ***grin*** TDD is supposed to make you brave, not cowards, and it's Ned's most excellent tool http://nedbatchelder.com/code/coverage/ that I recommend to TDD dogmatic cowards. Even if you don't want to use TTD, you will enjoy Ned's tool. It's GREAT. Thank you, Ned. Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
On Thu, 18 Jun 2015 06:39 am, Marko Rauhamaa wrote: Ned Batchelder n...@nedbatchelder.com: 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. You still need requirements and a design. Otherwise how do you know what tests you need to write? 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. That's certainly the more pedantic approach of TDD proponents. But frankly I expect that outside of TDD tutorials, nobody *really* starts off that small in practice. I know I don't. I would start with this function, and a separate test suite: # === application.py === def bracket(s): Return string s bracketed in parentheses. bracket(Hello) '(Hello)' return (%s) % s # === test_application.py === import application import doctest import unittest def load_tests(loader, tests, ignore): tests.addTests(doctest.DocTestSuite()) tests.addTests(doctest.DocTestSuite(application)) return tests if __name__ == '__main__': unittest.main() Then call python test_application.py to run the tests. Or even skip the test suite and just call python -m doctest application.py And from there, I would build up extra doc tests and unit tests as needed. The point is, I don't believe that there is any *necessity* to write deliberately failing tests for *trivial* functions that are only one or two lines. You can practically see that the function is correct without even a test. Deliberately making it fail has only one advantage: * Getting you used to failing tests and learning that they aren't in and of themselves a bad thing or something to be ashamed of; * Instilling the discipline to actually write tests. Er, that's two advantages. But really, in practice, how many trivial one liner functions do you end up writing, as a percentage of your entire application? Unless the app is pretty simple, chances are that percentage is very small. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
On Wednesday, June 17, 2015 at 6:34:23 PM UTC-4, Laura Creighton wrote: TDD is supposed to make you brave, not cowards, and it's Ned's most excellent tool http://nedbatchelder.com/code/coverage/ that I recommend to TDD dogmatic cowards. Even if you don't want to use TTD, you will enjoy Ned's tool. It's GREAT. Thank you, Ned. Laura So much for humility I guess. *blush*. Thanks! --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
On 6/17/2015 4:39 PM, Marko Rauhamaa wrote:
Ned Batchelder n...@nedbatchelder.com:
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 use what I might call 'smart TDD'. I think it a mistake to dismiss
TDD because 'stupid TDD' is possible, and maybe even extant.
The reason for having a test initially fail is to make sure that the
test is called. A unittest example:
class NoTest(unittest.TestCase):
def text_ohmygod(self):
assertEqual(True, False)
Why does this 'pass'? Within the last year, it was discovered that a
TestCase subclass in one of the Python test files was not being run. I
made a similar mistake in my own code. The more I do TDD
(intelligently), the more I like it.
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 bugs in Python, whether already fixed, on the tracker, or yet to be
recorded, are the result of CPython not originally using TDD of some
version. In my opinion, CPython maintenance and enhancement has
improved since some semblance of TDD was instituted. A runable test is
now the first stage for tracker issues.
The way it was explained to me was that in TDD you actually don't write
code to any requirements or design:
Writing sane code to pass tests based on requirements or a design is
intended to ensure that one is actually meeting the design.
you simply do the least to pass the tests.
The incantation I have read is 'simplest', not 'least'. I personally
interpret 'simplest' to include some presumption of sanity in relation
to the ultimate goal.
Thus, say you need to write a program that inputs a string and
outputs the same string surrounded by parentheses (the requirement),
One should write a reusable and easily testable *function* that takes a
string as input (and outputs the same string surrounded by parens).
Call the function paren_around.
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)
Doubly bad.
1. I consider mixing program i/o with function not related to i/o to be
a bad idea. TDD should cure one of this madness, not reinforce it.
2. The first test for smart TDD should best be with a falsey input (or
other corner or edge case). With this guideline, there is a good chance
the 'simplest code' will be augmented rather than replaced with
additional tests. A smart TDD test might be
assertEqual(paren_arount(''), '()')
The right TDD thing would be to satisfy the test with this program:
input()
print((hello))
This does not work. The above adds '\n' to the end of the string, which
is not part of the specification. A human may not notice, but an
automated test that captures stdout and compares with (hello) will
notice and fail.
That *ought* to be the first version of the program until further test
cases are added that invalidate it.
As a statistician, I know about the mistake of overfitting functions to
data. 'Teaching to the test' is a related mistake Smart TDD should not
reinforce bad practice. This simple code passes the initial testcase above.
def paren_around(s):
Return string s surrounded by '(' and ')'.
return '()'
Add a more generic (non-null) testcase.
assertEqual(paren_around('abc', '(abc)')
The irrelevant details should usually be ignored when augmenting the
code*. The simplicity of this example makes it easy to write a correct
assert, but is not relevant to the intent of the function.
def paren_around(s):
Return string s surrounded by '(' and ')'.
return '({})'.format(s)
Code added, with nothing deleted.
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.
The corresponding TDD approach is to write tests from the manual, and
then write code. One can also write tests from docs for existing code
- and then see if the code passes the doc-based tests. This is one way
people discover bugs.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
On Thu, Jun 18, 2015 at 6:39 AM, Marko Rauhamaa ma...@pacujo.net wrote: 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. I've seldom met a *user* manual that's truly the right way to start building, but there have been times when I've built *API* documentation prior to the code. That can work fairly well. I'll also often start a project with a copious set of notes that aren't quite user-facing, aren't quite programmer-friendly, but are somewhere in between. Here's a new project I'm starting now: https://github.com/Rosuav/ThirdSquare Prior to actually creating that repo, I'd done some thrash testing of the basic concepts (which is how I know that the basic idea will work - my thrash test achieved 100tps, massively exceeding the 40tps that I need, ergo it's worth proceeding to code), but the project itself started with the README, then the .sql files giving a basic run-down of the tables required. Now, and only now, I'm starting to look at actual code. Is that starting with the user manual? Not quite, but I think it captures the same concept that that's trying to capture. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
On 17/06/2015 23:09, Laura Creighton wrote: ps -- Marko, we have ample evidence that you are an extremely clever person. But the purpose of TTD is not to make clever code, but wise code. TTD in the hands of a fool will never produce that. But how else do you have to check that your design, while clever isn't _too damn clever_? Aren't you plagued with that problem? I am and TDD is the best thing I ever learned to keep that tendancy I have to write too clever code in check. Strange, I see no such evidence, just a person who lives firmly in cloud cuckoo land. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
On Wednesday, June 17, 2015 at 4:39:31 PM UTC-4, Marko Rauhamaa wrote: 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. The true TDD acolytes advocate a very idiosyncratic workflow, it's true. I don't do this, but I also don't consider myself a TDD person. I value tests a great deal, and put a lot of effort into them, but I don't write trivial functions to get my tests to pass and then go back to change them. But people whose opinion I value do advocate that, and it's possible that in time I will understand their methods and use them myself. Stranger things have happened... --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
On Wednesday, June 17, 2015 at 1:39:31 PM UTC-7, Marko Rauhamaa wrote: Ned Batchelder n...@nedbatchelder.com: 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 I had a Java class where we had to learn TDD, and that's the way TDD was taught to us, and I hated it. We watched a video of this guy explaining TDD with a hat that was red on the front and green on the back. It involved writing a simple failing unit test, then write code to fix it, then refactor the tests and/or code. As an in-class exercise, we had to write an implementation of Conway's Game of Life. I threw TDD out the window and just wrote the damn program in under 15 minutes, then another 10 minutes to write unit tests that tested every possible code branch and several invalid inputs. Meanwhile, the people doing TDD the right way didn't even have a complete program after over an hour. The brand of TTD we were taught would end up multiplying development time by at least a factor of 3, and by the time you were done, at least 75% of the tests you had written will have been removed due to rampant refactoring. IMO, that kind of TTD is an utter waste of time. -- https://mail.python.org/mailman/listinfo/python-list
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
On Wednesday, June 17, 2015 at 12:21:32 PM UTC-7, 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! You don't need interfaces with Python. Duck typing makes that all possible. This is perfectly valid: class Dog(object): def move(self): print Dog is moving class Car(object): def move(self): print Car is moving things = [Dog(), Car()] for thing in things: thing.move() Despite Dog and Car being completely different classes with no relationship with each other, the code runs just fine. -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
On 17/06/2015 21:39, Marko Rauhamaa wrote: Ned Batchelder n...@nedbatchelder.com: 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 Awesome, one of the funniest things I've read in years. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
On 17/06/2015 22:33, sohcahto...@gmail.com wrote: On Wednesday, June 17, 2015 at 1:39:31 PM UTC-7, Marko Rauhamaa wrote: Ned Batchelder n...@nedbatchelder.com: 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 I had a Java class where we had to learn TDD, and that's the way TDD was taught to us, and I hated it. We watched a video of this guy explaining TDD with a hat that was red on the front and green on the back. It involved writing a simple failing unit test, then write code to fix it, then refactor the tests and/or code. As an in-class exercise, we had to write an implementation of Conway's Game of Life. I threw TDD out the window and just wrote the damn program in under 15 minutes, then another 10 minutes to write unit tests that tested every possible code branch and several invalid inputs. Meanwhile, the people doing TDD the right way didn't even have a complete program after over an hour. The brand of TTD we were taught would end up multiplying development time by at least a factor of 3, and by the time you were done, at least 75% of the tests you had written will have been removed due to rampant refactoring. IMO, that kind of TTD is an utter waste of time. Couldn't agree with you more. To once again quote my favourite part of the Zen of Python, practicality beats purity. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
In a message of Wed, 17 Jun 2015 23:39:17 +0300, Marko Rauhamaa writes: Ned Batchelder n...@nedbatchelder.com: 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. Try it and see. 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. You have been talking to people who are beginners at TDD. They have been taught some hard and fast rules to keep them from the problem of over-designing. Or you may have been taking to fools. Both beginners and fools badly want to replace the wisdom that they don't have in their heads with some rules from somebody else's head. Beginners can work this way, and develop wisdom over time. Fools, pretty much by definition cannot. The way I usually work is to take a list of requirements from some user(s) and turn them into test cases. And then the job of design is to get from where I am 'have no code' to I can begin satisfying some of these requirements. Just because input() print((hello)) would satisfy the test you wrote doesn't mean it is a correct TTD thing to do -- because it doesn't get you any closer to solving the real problem your design is supposed to do. This doesn't mean that you need to write your tests in a more complicated way to prevent smart-asses from doing stuff like the above. It means that your tests should make you get closer to your goal. You will have to make a bridge of tests to get from 'I have nothing' to the first user supplied test you need to meet, but you do have a destination, and you need to go there. I teach a bunch of 11 year olds to program in python using TTD and pytest. A good number of them end up writing tests to test that the python standard library works the way they expect it to. In some sense, this is a waste of their time, but I resist the urge to tell them so. They are developing wisdom and understanding of the standard library, and confidence. When they are wiser, they can delete some of these superfluous tests, but as for now, these tests are a measure of their growing understanding. If you have oversimplified what you have been told, then it may be that you have missed this 'and I learned something here' bit they were telling you about, even if you think that they ought to have known it all along. Teaching design is hard. Teaching design to smart-asses who don't want to learn design at all but want some ruleset to be 'better than design' is impossible. But teaching design using TTD as a tool for design. Well, that is _wonderful_. 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. Unless the manual is bloody short, in which case it is a series of acceptance tests -- this is a rotten idea. The marketing department makes the user manual, the engineers implement it, and the users get screwed as they get, not what they want, but what somebody in marketing, or (only slightly better) engineering thinks that they wanted, or ought to want. If at all possible, you want the starting point of your software development to be a conversation between the people who are going to write the thing and the people who are going to use the thing, with particular attention to what the users are using now, and why they want something else instead of just more of the same. Marko ps -- Marko, we have ample evidence that you are an extremely clever person. But the purpose of TTD is not to make clever code, but wise code. TTD in the hands of a fool will never produce that. But how else do you have to check that your design, while clever isn't _too damn clever_? Aren't you plagued with that problem? I am and TDD is the best thing I ever learned to keep that tendancy I have to write too clever code in check. Laura again -- https://mail.python.org/mailman/listinfo/python-list
Re: Classic OOP in Python
Ned Batchelder n...@nedbatchelder.com: 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 -- https://mail.python.org/mailman/listinfo/python-list
