Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

Programming in Python

  1. Apr 8, 2009 #1
    I am new to computer programming, but if anyone familiar with Python has any suggestions or resources for a beginner, I would appreciate it.

    How useful is programming in Python? How does it compare to other programming languages?

    I've also heard that Python is relatively simple to learn; is this true in your experience?

    Thanks for your responses!
     
  2. jcsd
  3. Apr 8, 2009 #2

    Dick

    User Avatar
    Science Advisor
    Homework Helper

    Yes, it is simple to learn. And it's extremely powerful and coherent. Find out for yourself. Just learn it. There are endless numbers of tutorials and websites. Start learning how to use the objects and inheritance sooner rather than later, that's my advice. It will change your life.
     
  4. Apr 8, 2009 #3
    Hmm... Learn how to use objects and inheritance sooner rather than later... some good advice, I'm sure. =)

    I appreciate your response, and will look into the tutorials soon. Thanks!
     
  5. Apr 9, 2009 #4

    mgb_phys

    User Avatar
    Science Advisor
    Homework Helper

  6. Apr 9, 2009 #5
    http://www.python.org/doc/

    some google fun:
    http://code.google.com/
    http://code.google.com/apis/calendar/docs/1.0/developers_guide_python.html [Broken]

    I don't know python but I can use google python api and make things out of it.
     
    Last edited by a moderator: May 4, 2017
  7. Apr 9, 2009 #6
    Thank you all very much -- I have already begun checking out the links, and I can't wait to dive into some applications. :biggrin:
     
  8. Apr 9, 2009 #7

    robphy

    User Avatar
    Science Advisor
    Homework Helper
    Gold Member

  9. Apr 9, 2009 #8
    People, try harder. This is bad advice you're giving out.

    No, someone new to programming has no use for object oriented programming. Simple, small programs really are sequences of commands (imperative statements) - procedural, or maybe functional, styles are most natural for this. OOP is an unnecessary distraction for the new programmer. It distracts from far more fundamental issues - for instance, variable scoping, typing, procedures/functions, organizing code without objects...

     
  10. Apr 9, 2009 #9
    Yes, Python is probably the best language to start with. It is very easy to learn. It is also very useful - it is very popular, and has lots of very good third-party libraries (as mentioned here, you have SciPy for numerical work, and vPython for basic graphics...)

    Another important point is that you can program interactively, with an interpreter executing your code in real time - this is extremely good for experimentation and learning. You can examine objects and variables interactively too. You'll quickly see how useful this is.

    One very useful reference is the official docs for Python libraries,

    http://docs.python.org/library/

    I'm sorry I'm not sure which introductory books are good right now.
     
  11. Apr 9, 2009 #10
    Thank you very much, Signerror. Will follow your suggestions. :smile:
     
  12. Apr 9, 2009 #11

    mgb_phys

    User Avatar
    Science Advisor
    Homework Helper

    Sorry I had forgotten that dive into wasn't for new programmers.
    Thinking like a computer scientist in python is - it's aimed at high school students
    Free online version here http://openbookproject.net//thinkCSpy/ [Broken]
     
    Last edited by a moderator: May 4, 2017
  13. Apr 9, 2009 #12

    Dick

    User Avatar
    Science Advisor
    Homework Helper

    Really gotta disagree with you there, signerror. Unlike some other languages I could name, objects are not an 'add-on' in Python. They ARE the language. The rest of those concepts are the 'distractions'. That's what you learn when you've finally really gotten Python. Even a small program is more efficiently and flexibly structured as an object. It just fits. It's easy to start off in Python by emulating styles from other languages, which you can do, but when you finally get it, you realize that was wrong.
     
  14. Apr 9, 2009 #13
    I, for one, think that it's true one should start without objects, but...
    You should get there as soon as possible. Realistically, you should be comfortable with data types, branching, loops, and functions before you really start trying to use objects. Then, you should get good with using simple objects before using inheritance, polymorphism, etc.

    It would be a shame for anybody to learn to program nowadays without learning OO programming. I doubt anybody starts off learning by writing fully OO programs. People start off writing procedural code in an OO language.
     
  15. Apr 9, 2009 #14

    Dick

    User Avatar
    Science Advisor
    Homework Helper

    Sure they do. I couldn't agree more. I started by writing convoluted code using procedures and rearranging lists, coming from writing a lot of mathematica. My mistake. Feel free to start that way. There's probably a lot of other ways to make fundamental design errors. I'm just saying that the sooner you get beyond that the sooner you realize what a bad idea that was.
     
  16. Apr 11, 2009 #15
    I'm new too, and this has helped me a lot get my foot in the door.
    http://pythonbook.coffeeghost.net/ [Broken]
     
    Last edited by a moderator: May 4, 2017
  17. Apr 11, 2009 #16
    I'm really tired of hearing all the hype about OOP. Maybe it's a good paradigm for some situations. And maybe it works well for some programmers. But I have a hard time accepting that it is the "be all end all" of programming. I've been programming for over 30 years (assembly for (Z80, 8086, various micro-controllers), basic, vb.net, java, PHP and c#). And after hearing all the hype, and after trying it myself, and after not being able to "get" why it's better than procedural methods, it was nice to come across at least one other person that was not so "gung ho" about it.

    http://www.geocities.com/tablizer/oopbad.htm
     
    Last edited: Apr 11, 2009
  18. Apr 12, 2009 #17
    I write python for personal use, and I rarely feel the need to define my own classes. My code is just a bunch of functions that operate on simple data. If I need a data structure that has three or four properties, most likely I'll just use a list or tuple instead of an object--the tuple is more convenient. Also, frequently it's simpler to pass a function as an argument to my function, instead of using polymorphism. If I NEED object oriented features because my objects have so many properties that I need to name them to keep track of them, then I'll define a class, but on small personal projects of a few hundred lines or less, this doesn't happen much.

    I've done all the object oriented stuff in Java, too, plus I've cut my teeth on an armful of other languages. I just find functions to usually be a more convenient way of structuring code, at least on small personal projects.
     
    Last edited: Apr 12, 2009
  19. Apr 12, 2009 #18
    I think that OOP can contribute to making software projects better in several respects: it fosters reuse and encapsulation, for example. I doubt anyone would argue that OOP is the end-all solution for every software project, but the reasons why it has reached such a privileged status cannot be ignored.

    I've worked on a couple of scientific projects where OOP would have helped in the development efforts immensely. We didn't use it because the PI couldn't understand it, which I think is a real shame.

    I, for one, think that the OOP paradigm generally makes development a lot easier than not. Considering that most popular programming languages are OOP and procedural hybrids (that is, the objects' methods are written using procedural style), it's usually not so contrived or difficult to make an OO design procedural, or vice versa.

    I don't think functions operating on arrays is the way to go. I guess my position is that the number of objects and the complexity of the object hierarchy should be as low as possible... but no lower. Certain objects just suggest themselves... to willfully not use the benefits of OOP when practical seems superstitious to me.
     
  20. Apr 12, 2009 #19
    Object oriented programming comes at a cost besides the increased code length. Every time you add a new class and write functions to work with the class, you force someone else to figure out how your class works before they can use those functions. That decreases the likelihood that they are going to re-use your functions.

    If you have a function that takes a string and an int, it's more likely to be re-used than an equivalent function that takes a MyOwnObject, where MyOwnObject has two fields, MyOwnObject.stringVal and MyOwnObject.intVal.

    Of course, no one should say that user-defined classes are useless; they have their place, which is mostly in larger projects (beyond a few hundred lines), where you pass around enough fields in your data to want to name them. Also, hiding data behind an interface can be a good idea, to avoid tying your code down to an implementation. However, data hiding is only a concern on larger projects; for smaller projects it tends not to be worth the time and added complexity.
     
  21. Apr 13, 2009 #20
    "Object oriented programming comes at a cost besides the increased code length."
    OOP facilitates software development on large projects. There is actual evidence supporting my claim... I will be happy to look for it if you are interested. Apparently, the increased length of code is not such a hindrance.

    "Every time you add a new class and write functions to work with the class, you force someone else to figure out how your class works before they can use those functions."
    Of course, this is true of *any* code you write, whether it be OO, functional, logic, ... People will have to understand how your code works before they can use it. The argument is that it's easier for people to intuitively grasp how objects behave than it is to grasp how mathematical functions or sentences of propositional logic.

    That decreases the likelihood that they are going to re-use your functions."
    Since reuse is one of the main benefits of OOP, I'm sure you'll agree that while OOP may not be perfect, it is often better than the alternatives. Just because *you* have a harder time understanding OO code doesn't mean it's inferior.

    "If you have a function that takes a string and an int, it's more likely to be re-used than an equivalent function that takes a MyOwnObject, where MyOwnObject has two fields, MyOwnObject.stringVal and MyOwnObject.intVal."
    That's a little contrived, and you know it. Any paradigm can be made to look silly if you misuse it. Consider the following code to calculate the product of two integers.

    Code (Text):

    product_of_two(x,y) : divide(subtract(square(subtract(x,y)), add(square(x), square(y)),-2)
     
    See, so using procedures is stupid by the same logic. If you understood how to use OOP, you would see that your code is just as unnecessary and contrived as is mine.

    And I disagree that OOP is only good for large projects. While it's true that larger projects get even more benefit from OOP, even small programs can benefit from (appropriate) usage of OOP - which goes well beyond defining a few record types to store data. Lots of programs tend to start small and get bigger; the global-variable, goto, pure-procedural style of programming is simply not scalable. You invariably end up with a nightmare of interconnected global variables and parallel arrays and function pointers that only you and the other people who were with you at the time can comprehend, and if you lose the documentation (assuming you make any at all, and if your PI is not in CS, then odds are the documentation will be slim to none) then good luck knowing what you were thinking when you try to figure it out after a week of vacation.
     
Know someone interested in this topic? Share this thread via Reddit, Google+, Twitter, or Facebook