Re: Functional vs. Object oriented API
Max Bucknell wrote: Hi, I'm currently learning Python, and it's going great. I've dabbled before, but really getting into it is good fun. To test myself, and not detract too much from my actual studies (mathematics), I've been writing my own package to do linear algebra, and I am unsure about how best to structure my API. For example, I have a vector class, that works like so: a = Vector([2, 7, 4]) b = Vector.j # unit vector in 3D y direction I also have a function to generate the dot product of these two vectors. In Java, such a function would be put as a method on the class and I would do something like: a.dot_product(b) 7 Not necessarily. That would only happen if that code was designed that way. It's quite possible, and desirable, that the dot product isn't implemented as a member function of the vector data type, and instead is implemented as an operator to be applied to two object. and that would be the end of it. But in Python, I can also have: dot_product(a, b) 7 Which of these two are preferred in Python? And are there any general guidelines for choosing between the two styles, or is it largely a matter of personal preference? The separation of concerns principle is a good guideline. This doesn't apply exclusively to Python; it essentiallyl applies to all programming languages. http://en.wikipedia.org/wiki/Separation_of_concerns There are significant advantages in separating the definition of a data type from the definition of the operations that are to be applied to it. If operations are decoupled from the data type then it's possible to preserve the definition of that data type eternally, while the operators that are written to operate on it can be added, tweaked and removed independently and at anyone's whims. Hope this helps, Rui Maciel -- http://mail.python.org/mailman/listinfo/python-list
Re: Functional vs. Object oriented API
In article 51678b94$0$29977$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: - If you have a complicated interface, or data with complicated internal state, the best solution is to use a custom object with methods. - But if your interface is simple, and the data is simple, it is more efficient to stick to lightweight built-ins [...] - If the *only* reason you use a class is to keep the data together, that's very much a Java design. As part of our initial interview screen, we give applicants some small coding problems to do. One of the things we see a lot is what you could call Java code smell. This is our clue that the person is really a Java hacker at heart who just dabbles in Python but isn't really fluent. It's kind of like how I can walk into a Spanish restaurant and order dinner or enquire where the men's room is, but everybody knows I'm a gringo as soon as I open my mouth. It's not just LongVerboseFunctionNamesInCamelCase(). Nor is it code that looks like somebody bought the Gang of Four patterns book and is trying to get their money's worth out of the investment. The real dead giveaway is when they write classes which contain a single static method and nothing else. That being said, I've noticed in my own coding, it's far more often that I start out writing some functions and later regret not having initially made it a class, than the other way around. That's as true in my C++ code as it is in my Python. In my mind, classes are all about data. If there's no data (i.e. no stored state), you should be thinking a collection of functions. On the other hand, if there's ONLY data and no behavior, then you should be thinking namedtuple (which is really just a shortcut way to write a trivial class). Once you start having state (i.e. data) and behavior (i.e. functions) in the same thought, then you need a class. If you find yourself passing the same bunch of variables around to multiple functions, that's a hint that maybe there's a class struggling to be written. -- http://mail.python.org/mailman/listinfo/python-list
Re: Functional vs. Object oriented API
On 04/12/2013 10:19 AM, Roy Smith wrote: As part of our initial interview screen, we give applicants some small coding problems to do. One of the things we see a lot is what you could call Java code smell. This is our clue that the person is really a Java hacker at heart who just dabbles in Python but isn't really fluent. It's kind of like how I can walk into a Spanish restaurant and order dinner or enquire where the men's room is, but everybody knows I'm a gringo as soon as I open my mouth. It's not just LongVerboseFunctionNamesInCamelCase(). Nor is it code that looks like somebody bought the Gang of Four patterns book and is trying to get their money's worth out of the investment. The real dead giveaway is when they write classes which contain a single static method and nothing else. That being said, I've noticed in my own coding, it's far more often that I start out writing some functions and later regret not having initially made it a class, than the other way around. I've absolutely noticed the same thing for myself, over and over again. I can't remember writing a class that I've regretted is not a few functions, although it must have happened a few times. -m -- Lark's Tongue Guide to Python: http://lightbird.net/larks/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Functional vs. Object oriented API
Roy Smith r...@panix.com As part of our initial interview screen, we give applicants some small coding problems to do. One of the things we see a lot is what you could call Java code smell. This is our clue that the person is really a Java hacker at heart who just dabbles in Python but isn't really fluent. ... It's not just LongVerboseFunctionNamesInCamelCase(). Nor is it code that looks like somebody bought the Gang of Four patterns book and is trying to get their money's worth out of the investment. The real dead giveaway is when they write classes which contain a single static method and nothing else. I may have some lingering Java smell myself, although I've been working mostly in Python lately, but my reaction here is that's really I don't know BASIC smell or something; a class that contains a single static method and nothing else isn't wonderful Java design style either. That being said, I've noticed in my own coding, it's far more often that I start out writing some functions and later regret not having initially made it a class, than the other way around. That's as true in my C++ code as it is in my Python. Definitely. Once you start having state (i.e. data) and behavior (i.e. functions) in the same thought, then you need a class. If you find yourself passing the same bunch of variables around to multiple functions, that's a hint that maybe there's a class struggling to be written. And I think equally to the point, even if you have only data, or only functions, right now, if the thing in question has that thing-like feel to it :) you will probably find yourself with both before you're done, so you might as well make it a class now... DC -- http://mail.python.org/mailman/listinfo/python-list
Re: Functional vs. Object oriented API
David M Chess於 2013年4月12日星期五UTC+8下午11時37分28秒寫道： Roy Smith r...@panix.com As part of our initial interview screen, we give applicants some small coding problems to do. One of the things we see a lot is what you could call Java code smell. This is our clue that the person is really a Java hacker at heart who just dabbles in Python but isn't really fluent. ... It's not just LongVerboseFunctionNamesInCamelCase(). Nor is it code that looks like somebody bought the Gang of Four patterns book and is that maybe there's a class struggling to be written. And I think equally to the point, even if you have only data, or only functions, right now, if the thing in question has that thing-like feel to it :) you will probably find yourself with both before you're done, so you might as well make it a class now... DC If it is not time-critical and no needs to convert into CYTHON then it does not matter too much. But a well wrapped class structures with good documents can help others to use the python codes a lot. If the part is intended to be time-critical in the low level part, then avoiding seeking 4 levels of methods and properties inside a loop is helpful in python programs to be executed in the run time. -- http://mail.python.org/mailman/listinfo/python-list
Re: Functional vs. Object oriented API
On Thu, 11 Apr 2013 00:16:19 +0100, Max Bucknell wrote: For example, I have a vector class, that works like so: a = Vector([2, 7, 4]) b = Vector.j # unit vector in 3D y direction I also have a function to generate the dot product of these two vectors. In Java, such a function would be put as a method on the class and I would do something like: a.dot_product(b) 7 and that would be the end of it. But in Python, I can also have: dot_product(a, b) 7 Which of these two are preferred in Python? Both of them! Python is a pure Object Oriented language in that all values are objects. (Unlike Java, where some values are unboxed primitives, and some are objects.) But Python does not force you to use Object Oriented syntax. You can where it makes sense. If not, you aren't forced to. And are there any general guidelines for choosing between the two styles, or is it largely a matter of personal preference? I would put it like this: - If you have a complicated interface, or data with complicated internal state, the best solution is to use a custom object with methods. - But if your interface is simple, and the data is simple, it is more efficient to stick to lightweight built-ins. For example, a simple three- tuple like (1, 4, 2) is probably more efficient than a Vector(1, 4, 2). (Although there are ways to make classes more lean, and still give them methods.) - If the *only* reason you use a class is to keep the data together, that's very much a Java design. In Python, you should put the functions in a module, and use that. E.g. if your class looks like this: class MyClass: def __init__(self, data): self.data def spam(self): return spamify(self.data) def eggs(self, n): return eggify(self.data, n) def aardvark(self): return aardvarkify(self.data) then using a class doesn't give you much, and you should expose spam, eggs and aardvark as top-level functions that take data as an argument. You might like to watch this video from PyCon: http://pyvideo.org/video/880/stop-writing-classes or www.youtube.com/watch?v=o9pEzgHorH0 and then read this response: http://lucumr.pocoo.org/2013/2/13/moar-classes/ Personally, I think that Armin Ronacher's response is important, but suffers from a fatal flaw. Monolithic code is Bad, agreed. But classes are not the only way to avoid monolithic code. Small, lightly coupled functions are just as good at breaking down monolithic code as classes. Some might even argue better. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Functional vs. Object oriented API
Hi, I'm currently learning Python, and it's going great. I've dabbled before, but really getting into it is good fun. To test myself, and not detract too much from my actual studies (mathematics), I've been writing my own package to do linear algebra, and I am unsure about how best to structure my API. For example, I have a vector class, that works like so: a = Vector([2, 7, 4]) b = Vector.j # unit vector in 3D y direction I also have a function to generate the dot product of these two vectors. In Java, such a function would be put as a method on the class and I would do something like: a.dot_product(b) 7 and that would be the end of it. But in Python, I can also have: dot_product(a, b) 7 Which of these two are preferred in Python? And are there any general guidelines for choosing between the two styles, or is it largely a matter of personal preference? Thanks for reading, Max. -- http://mail.python.org/mailman/listinfo/python-list
Re: Functional vs. Object oriented API
Hi Max, In Python, we prefer readability over anything else. The simpler you can write it, the better it can be understood. That said, I've never considered using (i, j, k) as a vector component before. I've always done something akin to: vector = Vector(2, 4, 6) print (vector.normalize().y) However, if you use the mathematical definition of a vector, with standard symbols: v = x*i + y*j + z*k Then I believe vector.j is a much choice. As long as your documentation states it's read-only, I think most mathematicians will love that notation. . As far as dot products go, there isn't really a big difference between the two forms you have there. Both are equally as readable. When C++ was invented people had already debated about the two forms. There isn't a general consensus on this debate, but most would probably agree that overloading the * operator of a vector to do dot product is a bad idea, since some people want cross product, or per-component multiplication. At the end of the day, dot() or dot_product() is more readable, and it doesn't matter if you have it as a function in or outside of a vector's class. Cheers, Xav -- http://mail.python.org/mailman/listinfo/python-list
Re: Functional vs. Object oriented API
On Wed, Apr 10, 2013 at 5:16 PM, Max Bucknell mpwb...@york.ac.uk wrote: I also have a function to generate the dot product of these two vectors. In Java, such a function would be put as a method on the class and I would do something like: a.dot_product(b) 7 and that would be the end of it. But in Python, I can also have: dot_product(a, b) 7 Which of these two are preferred in Python? And are there any general guidelines for choosing between the two styles, or is it largely a matter of personal preference? The advantage to the latter is that it potentially allows you to implement dot products for other types using the same function. Using the method, a must be a Vector instance, but using the function it remains unrestricted. This is useful because functions are first-class objects in Python. Suppose that you find yourself wanting to pass that dot_product operation to some other function, e.g. map(). Using the function version you just pass in dot_product -- map(dot_product, seq1, seq2) -- and the mapped sequences can then contain any types that dot_product has been implemented to handle. Using the method version, you would have to pass in the unbound Vector.dot_product method -- map(Vector.dot_product, seq1, seq2), and then the method will only accept Vector instances in seq1. -- http://mail.python.org/mailman/listinfo/python-list
