Total Pageviews

Tuesday, July 17, 2012

Why I Love To Hate Python


 Ah Python, how I love to hate you.
 The Python language was originally developed to simplify programing, and to that end, it has succeeded.
 The problem? It's completely useless for real world development.
 True you can write good programs to do all the common tasks, however when one wants real functionality with Python, they are in for a world of frustration.
 The core of most of the problems, is Python is not portable (explained later) and that most of the Python development community became inactive in the early 2000's, as Java and other languages came into their own.
 Python has many different versions, with enough differences between them, that programs written in one version, will not work in another version. In simple terms, Python is NOT backwards compatible, unlike a lot of other languages.
 A program written in 2.6, most likely will not run in 2.4. A program written in 3.x will not work with any of the 2.x versions, and 2.x will not work in 3.x .
 The 2to3 adapter is a joke to get to work correctly, and full of bugs.

 When I mentioned portability earlier, I am talking about adaptability and the ability to distribute your programs.  
 Most other languages have built in compilers, that spit out executable files automatically . 2 other languages I use, Java and C++ can easy spit out executable that are platform independent. Python? Nope. One has to search around for a third party compiler.
 There are only 2 major ones known, both with their own problems, cx_freeze, and Py2exe.
 Cx_freeze will not compile files correctly for Windows 7 ( I tried for 3 hours ), and Py2exe is a steaming pile of crap!
 Everyone recommends Py2exe, but apparently no one actually tried to use it. The executable that are crapped out by this, are platform, and version specific.
 Let me backup a little bit, and explain how this headache works.
 Once you complete a program you wish distribute, you have to take careful note of which version of Python you used.
 From there you much figure out which Visual C Runtime library you need to include with the program -  Python for Windows was compiled in Visual C.
 Once that is accomplished, you need to create a setup.py file for your program. Than run some commands from DOS. I made my life a lot easier, by creating a .bat that automatically did this step for me.
 After this, it spits out an executable, that will run on your computer. Repeat - It - will - run - on - YOUR - computer. Now with the files in hand, you need to find a packaging tool. I use "Install Creator " since it's easy to use, and free. http://download.cnet.com/Install-Creator/3000-2383_4-10218346.html.
 Package your files, executable and the runtime libraries, and your done - sort of.
There are many dependency files that Py2exe will not include in the executable, and are illegal to distribute ( Remember Python for Windows, was compiled in Visual C ).
 The major dependency files are standard windows files, however there is one that is Windows version specific. If your using Windows 7, folks on any other version of windows ( XP, Vista, ... ) will not be able to use your program ( same is true for programs compiled in other windows versions ) .
 Why not just have them download the same version of Python, you may ask?
 To a casual computer user, getting a .py file to work would be a nightmare. By default .py is NOT ASSOCIATED with Python.exe( and has been that way since Windows 2000 ) . Attempting to manually associate .py will not work. Easiest solution is creating a .bat file to open the .py as such ...



python Program_Name.py

Why on the gods green earth, do I have to do this?

 Now we move on to Python, and the WEB. Python has many built in features to deal with networking and various tasks related to the internet, however you will find even in the latest version ( 3.2 ) many of them are STILL buggy and preform erratically. ( do a search on the topic ).
 What about web hosting and and server functions ?
 Python will not run naturally on any modern web server. To do that, one needs to find third party extensions for the server. I have only found 2 - both of them require a very outdated version of Python, and nether one is compatible newer server software ( I tried for over 3 months with MANY different servers ).
 The companies that actually run Python on their servers, use custom made programs written in other languages , such as C and Java. In simple terms, you have to write your own parser in another language http://en.wikipedia.org/wiki/Parsing to get Python to function on your server.
 What about a server written in all Python you may ask. It's possible to write one in under 4 hours, however networks do not like Python for some reason. With out touching anything, I can get my custom written  Java and C++ servers up and running with no issues. Python, however, gets rejected by my network. From what I have read, I need to download some adapters to get it to work, but I am not going to risk screwing up my network.

 What about games?
If your writing a text based game, Python is great for that, however it naturally does not support anything graphical. Well Python does have Turtle and TK, but they are useless in game creation.
 For simple 2D games ( think Sega Genesis or Super Nintendo ) , the addon called Pygame works great. I seriously have no complaints about it, and recommend it to any one who wants to learn about game development.
 For 3D games, one has to rely on prebuilt game engines. There are 3D addons for python it's self, but they are VERY slow and useless for games.
 The 2 major ones would be Ogre and Panda 3D. Both of them use Python for game logic, while doing the 3D rendering and other functions in C. They both have their headaches, so do your research on them.

 Lastly we move on to functionality / fundamentals. I should have included this section first, but I had to vent my frustrations about other things.
 I mentioned earlier that the development community had mostly became inactive in the early 2000's, and it shows. Many addons require a specific version of Python to work. Many of them are seriously outdated, and "abandon" by their development teams.
 The problem is you need third party addons to make Python useable, and end up with several versions of Python on your computer.
 I recently did a purge of my system of most of the Python - junk - I had building up. I removed 5 different standard versions of Python, and 2 "specialty" versions.
 I am currently running 2.7, mostly due to the fact 3.x is incompatible with 95% of the addons out there. I also find it funny the core Python developers are updating both 2.x and 3.x at the same time, realizing that almost no one makes addons for Python anymore.
 It's mind numbly frustrating to be exposed to other, more "useful" languages, and coming back to Python to find what you can easy do in the other languages, can not be dome without third party addons.  So you download addon after addon, trying to find one that actually still works, installing many different versions of Python because each addon requires a specific version, and generally making one big mess of your hard drive. At the end of the day, you just end up going back to the other languages, due to the pounding migraine headache Python causes.

 Here we are at fundamentals. Python was supposedly based on the principals of "Zen Of Python" http://www.python.org/dev/peps/pep-0020 , however the language it's self violates these "rules" quite a bit. I will not go into great details, but if you do some research on how Python handles classes, you'll see some of what I am talking about .... C++ + stupidity = Python Classes.

 I think I have ranted enough about Python today. It may be a great tool for those that are new to programming, but is completely worthless inn practical application.

32 comments:

  1. I ran across your post and I liked it because it confirms my prejudices (and experience!). I am an experienced programmer but I have been avoiding python. However recently I have been taking online courses and many of them use python in their exercises.

    A major problem for me in addition to the lack of compatibility beiween versions is python's weirdnesses. For example, the whole shallow vs. deep copy issue gives me the willys. Another weirdness I recently ran across this one on testing strings
    >>> a = "b!"
    >>> b = "b!"
    >>> a is b
    False
    >>> a==b
    True

    So, here is my question. Can you point me to ideas for "safe" programming practices to reduce the chances of getting into trouble. For example, does it make sense to always use the deepcopy function with lists and other mutable data types? When to use "is" and when to use "=="?

    Also the converse would be helpful. What are other python weirdnesses for people coming from other languages like C?

    BTW, posting a comment on blogspot is a PITA. Reminds me of the cone of silence on get smart. You avoid spam but legit people quit trying to comment.

    ReplyDelete
    Replies
    1. Wait. What's wrong with the above example? The keyword is in python checks to see whether the two variables point to the same object. The == operator checks to see whether the value stored in both objects is the same.

      Delete
    2. The code snippet seems like a perfect demonstration of the desired difference between testing for identity versus testing for equality. This is a concept that is common to many languages, and I don't think the way Python handles it is unusual.

      Delete
    3. For example, the Python 'is' operator is precisely the same as is offered by the C# 'Object.ReferenceEquals(a, b)' method.

      Delete
    4. You almost never need to use deepcopy. The equivalent in C is if you had a data structure - a linked list or tree you were manually maintaining. Occasionally you would want to copy trees wholesale. Then you would use deepcopy. But almost always, a second reference to the same in-memory tree is what you actually want. Then you use assignment.

      To imagine the difference between equality (==) and identity (is): Perhaps your tree is a DOM, and you're searching for a node which contains the text "hello". You would visit each node in turn, and would test whether (node.content == "hello"). This is an equality check because you want to find all the nodes which equal a particular value (i.e. two different areas of memory contain the same content) Whereas if you wanted to check whether a node is the root of the tree, you would instead test using identity (node is root) because you are interested in a particular node. (i.e. two different pointers actually point to the same area in memory)

      When I moved from C / C# to Python, one thing that helped me think about it was to remember that every variable or function parameter is like a reference to type object, and *everything* in the language is an instance of type object (or its subclasses). E.g. instances are, obviously, but so are string and integer literals in your code (so "hello".upper() works), and functions, classes themselves, as well as modules - these are all instances of various classes, each of which has methods and attributes you can mess with.

      So, for example, if you define a class, and then find out the class of your class (not of an instance), then you'll have found the class that is used to generate all classes. This is an object called 'type'. Just like you call any class to generate an instance of that type, so you can call 'type' to generate a new class. The parameters you pass to 'type' will determine the properties of the returned class.

      Delete
  2. So, your primary complaint seems to be that Microsoft's redistribution terms mean you need to create a proper Windows installer in order to ship the CPython runtime as part of a Windows application? This is true, and unfortunate. However, Microsoft have chosen to do things that way so they can provide security updates to the C runtime when appropriate.

    The alternative is Oracle's model for Java where the they run their own Java updater and automatic update services. The PSF doesn't currently have the resources for that, instead relying on the distribution-specific packaging systems. This works reasonably well on platforms with a good open source dependency management ethos (such as the various Linux distributions and the Mac OS X Homebrew system), but less well on Windows.

    As far as versioning goes, if you use features that were only added in a later version, of course your software won't work in an earlier version (try using C99 features on a C89 compiler, or Jave SE7 features in SE6). While broken or ill-advised features are occasionally deprecated, this is not common, and comes with a DeprecationWarning in preceding releases. There is indeed a compatibility break between the 2.x and 3.x series in order to address some underlying issues in the text model, which I have written about more extensively elsewhere (see http://python-notes.boredomandlaziness.org/en/latest/python3/questions_and_answers.html). However, there are also many more options than trying to use the 2to3 tool for migration, most notably writing to the large common subset between the two versions for 2.6+ and 3.x with the aid of the "six" compatibility library from PyPI.

    As far as web servers go, I assume you're also talking about Windows hosting rather than Linux? (Linux systems have a plethora of options, including Apache+mod_wsgi, as well as the currently fashionable nginx+gunicorn). On Windows, the Apache+mod_wsgi combination should still work, but I have no idea about any proprietary web servers (including IIS).

    The Python Package Index provides a repository where you can clearly identify whether or not a project is under active development (and a great many of them are), before deciding whether or not to rely on it as a dependency. Assessing the responsiveness of potential upstream dependencies before adopting them is simply good engineering practice, just as one should assess the reliability of a company before deciding to rely on their software or services.

    Really though, most of the complaints in this post are so thoroughly unlike the experience of active Python users, and so obviously false given the wide variety of real world applications built using Python (for example, see https://us.pycon.org/2013/sponsors/ - make sure ad blockers are switched off, or the 'sponsors' in the URL may put them off), that many people will just dismiss it without taking the time to see if it includes any valid observations (such as the genuine problems posed by Microsoft's policies requiring installer-based redistribution of the C runtime rather than just providing the appropriate C runtimes as part of the base OS as Linux distributions do).

    ReplyDelete
    Replies
    1. You didn't actually read the post, did you. Instead you skimmed it for keywords.
      I can not reply to what you have stated, since it is so far off of what was posted.

      Only thing I will comment on is what you said in the bottom - Name me one real world application that is written in pure Python.

      Delete
    2. Nick Coghlan's comment seemed to address the points in your post perfectly. I was about to write a very similar reply myself. He already did name many projects and companies that use Python!

      Delete
  3. python is a scripting language which has advantages over compiled language in specific contexts. Its a goddamn feature which is the reason they exist parallel to compiled language.

    And you hate python because in windows .py is NOT ASSOCIATED with Python.exe? seriously? and the solution is to make a .bat?

    ReplyDelete
  4. > most of the Python development community became
    > inactive in the early 2000's

    Hey. This doesn't seem to be the case. What are you basing this observation on?

    Python the language has more committers, and more commits, than it has ever had.

    Similarly, the number of packages on the Python Package Index (PyPI) seems quite healthy. While there are only about half the number of packages as there are on, say, rubygems, there are still significantly more than there are on similar .NET packaging repositories.

    As of Jan 2013, the growth has not just been uninterrupted, but is accelerating. (e.g, see. http://www.modulecounts.com/) It recently surpassed the package count on CPAN, which is well-known as a very successful packaging repository.

    ReplyDelete
  5. > Python is NOT backwards compatible, unlike a lot of
    > other languages. A program written in 2.6, most likely
    > will not run in 2.4.

    Usually 'backwards compatible' is used to mean that a program written in 2.4 should still work under 2.6 - not the other way around. It's difficult to see how a program using features from later versions of a language could still work under earlier versions of the same language, no matter what programming language you're talking about. That seems to be a logical impossibility.

    For the vast majority of cases, Python actually preserves backwards compatibility very well. It's regarded as an important criteria in all the discussions of new language features, and is only ever broken in the most exceptional of circumstances. In all of its twenty year history, there have only been very very few breaks in backwards compatibility. Most pertinent to modern-day developers is the move from Python 2 to Python 3.

    This change was well-publicised and planned, with much careful thought given to providing migration plans for existing projects. If you want to migrate to Python 3, then the conversion of most medium sized project is sometimes trivial, or sometimes is a few hours of work. On the other hand, if you don't want to migrate, or want to do it later, then Python 2.7 is still supported and receiving bugfixes and security updates. Nobody is being forced to update.

    So is this really such a big deal? How has it caused problems for you?

    ReplyDelete
  6. This comment has been removed by the author.

    ReplyDelete
  7. > The 2to3 adapter is a joke to get to work correctly, and full of bugs.

    I'm sorry to hear you had problems with it, but people don't generally report it to be buggy.

    It doesn't claim to 100% convert your project from Python 2 to Python 3. It claims to do 90% of the donkey work, leaving you to focus your time on converting the occasional bits that can't unambiguously be converted automatically.

    What sort of bugs did you encounter? Did it crash? Did it produce output code that behaved differently from the input code? Obviously bug reports would be gratefully received.

    ReplyDelete
  8. This comment has been removed by the author.

    ReplyDelete
  9. > Most other languages have built in compilers, that spit
    > out executable files automatically . 2 other languages
    > I use, Java and C++ can easy spit out executable that
    > are platform independent. Python? Nope. One has to
    > search around for a third party compiler.

    You seem to have misunderstood what a 'compiler' is, and C++ executables are not platform independent, but leaving that aside, your overarching point, that producing a stand-alone executable from Python is harder than it ought to be, is still valid, and deserves to be acknowledged.

    I absolutely agree that this process ought to be easier. The problem has a few causes.

    1) For many people, distributing as source is adequate. If your audience is other developers, then this will get you 99% of the way there for 5% of the effort, so the motivation to fix this problem is lower than it could be. I strongly feel that if your audience is not developers, i.e. is "real people", then distributing as source is never appropriate, so this is still a real problem.

    2) You're developing on Windows, and as Nick points out, Microsoft have a few legal policies in place which make all of this harder than it ought to be. Some of these problems go away, or are reduced, if you buy a copy of Visual Studio (not Express) and gain the rights to redistribute microsoft's C runtime with your executable. Python core developers have all been given a copy of Visual Studio, and are generally very proficient developers, so they generally don't perceive this to be a problem at all - for them it's easy.

    It has to be said though, if you're doing projects which aren't constrained to be on Windows, then if you're a professional developer then you really you owe it to yourself to become proficient on other platforms too.

    ReplyDelete
  10. > Python has many built in features to deal with networking and
    > various tasks related to the internet, however you will find even
    > in the latest version ( 3.2 ) many of them are STILL buggy and
    > preform erratically. ( do a search on the topic ).

    This isn't generally perceived to be the case. e.g. the 'requests' library is generally regarded as a magnificent way to make web requests. Could you be more specific?

    ReplyDelete
  11. > Python will not run naturally on any modern web server.
    > To do that, one needs to find third party extensions for the
    > server.

    This is just silly. Python works extremely well with a large variety of web servers, for example see the list at:

    http://www.wsgi.org/en/latest/servers.html

    which includes workhorses like Apache, and some more trendy ones too.

    Many large, famous websites are or were formerly written in Python, such as YouTube, canonical and all Ubuntu's online functionality, Dropbox, and thousands of smaller websites are written in Python.

    ReplyDelete
  12. > The companies that actually run Python on their servers,
    > use custom made programs written in other languages

    While this is an option and I'm sure a small number of people do it, for reasons of their own, it absolutely isn't true that many people do this. Most people just write ordinary Python programs on the server.

    ReplyDelete
  13. > What about a server written in all Python you may ask.
    > It's possible to write one in under 4 hours

    This is puzzling. If you mean a UDP 'ping' server which does nothing except reply, then it's about 5 lines, I think. Or if you mean an http server, one is built into the Python stdlib so you just call it. Are we talking at cross-purposes? What did you actually mean?

    ReplyDelete
  14. > however networks do not like Python for some reason.

    Obviously requests are just requests, and packets are just packets. It doesn't matter what language generates them. I'm sorry to hear you've had some problems, but this doesn't seem to be a problem anyone else has.

    ReplyDelete
  15. > For 3D games, one has to rely on prebuilt game engines.
    > There are 3D addons for python it's self, but they are VERY
    > slow and useless for games

    This simply isn't true. I've written a few Sunday afternoon projects which make raw OpenGL calls from Python, with hundreds of complex geometries whirling around in 3D at 60fps on a very modest old laptop.

    ReplyDelete
  16. > Many addons require a specific version of Python to work.

    It's true that many Python packages only work under a range of Python versions. Usually that range is determined by the oldest version of Python which supports all the language features used by that package, up to the current version of Python. The major exception to this rule is the single back-compatibility break between Python 2 and 3.

    But this isn't unusual - it's inevitable. If your language is changing at all, then any project which uses new language features will, obviously, not work in older versions of the language. How could you expect otherwise?


    > Many of them are seriously outdated, and "abandon" by their
    > development teams.

    I think this is more a statement about human beings and about software projects in general than it is about Python. Possibly Python does lower the bar to entry somewhat, so there are more half-hearted projects started which never go anywhere. That's not a problem though, it's a symptom of a healthy system - "let a thousand flowers bloom" and all that.

    ReplyDelete
  17. > The problem is you need third party addons to make Python
    > useable, and end up with several versions of Python on your
    > computer.

    I'm sorry to hear you had a frustrating time installing different versions of Python to try out different packages which, by the sounds of it, didn't turned out to be rubbish.

    One rule of thumb that might help you out in future is that if a package isn't well documented and doesn't obviously show that it works in the current latest version of Python (which means either 3.3 or 2.7) then that is a low quality package and I would recommend not even trying it out unless you're are desperate.

    ReplyDelete
  18. > 3.x is incompatible with 95% of the addons out there.

    Going to PyPI to actually measure, rather than BS, I see 35 screensful of "Python 3" packages, versus 41 screensful of "Python 2" packages. This makes sense, because we're about halfway through the period of five years that was estimated for most projects to make the transition.

    When you restrict that to packages that actually matter, then the proportion gets even better:
    http://python3wos.appspot.com/

    ReplyDelete
  19. > I also find it funny the core Python developers are
    >updating both 2.x and 3.x at the same time,

    This isn't true. Once Python 3 was released, development on new features was halted in the Python 2 series. A few backwards compatible features like set literals and dictionary comprehensions were backported into Python 2.7, and security fixes and bugfixes are still backported, so that users of Python 2.7 can continue to use it safely. But there will never be a Python 2.8, and this has been well-understood for years.

    ReplyDelete
  20. > It's mind numbly frustrating to be exposed to other,
    > more "useful" languages

    I'm sorry to hear that you've had some frustrations with Python, but your experiences are not representative of most people's. If I were you, I'd be curious to find out why your experiences are so different from those reported by other people.

    From the topics you've chosen to complain about, it sounds like you've been in a difficult situation: Not having much experience on different platforms, or with open source projects, and producing Python on your own, without any real guidance or mentorship. Maybe it's your first dynamic language, and you're not really self-sufficient outside of the familiar environments of a big corporate-backed language IDE. This would test anyone's abilities, and it's no wonder you've struggled to understand so many things.

    ReplyDelete
  21. Anyone interested in a sensible comparison of Python to other languages might be interested in this academic paper, in which the same scientific number-crunching was implemented in Fortran, C and Python. (These languages were chosen because they are very popular in the scientific community, for reasons made clear in the article)

    http://arxiv.org/pdf/1301.1334v1.pdf

    ReplyDelete
  22. It seems that OP missed the point of scripting language. Why OP uses bat when C++ or Java is 100x times more powerful?

    ReplyDelete
  23. This was a very funny read,
    probably the most clueless python-article I came across in a decade.

    ReplyDelete
  24. Time to wake up from the nightmare, blogger.. You would rather want to go and bang your head when you see in reality that the best and best ever programming language (and yes its programming language, not only scripting language) that gives programming a new meaning is python...

    ReplyDelete
  25. I really enjoy really the PROS and CONS about python as i have never read anything critical about Python.
    Thank you for your contributions and sharing your expertise.
    Sharing my own experience lately, I was looking for a tool to make crossPlatform GUI,
    I have tried MonoDevelop + GTK which I could install due the dependency problem,
    I have tried visual studio which is so heavy with the Dot Framework and does not run on Linux and Max.
    Java does not have a default text editor and code for a simple window is ugly
    http://java.about.com/od/creatinguserinterfaces/ss/simplewindow_2.htm

    Than I have came across Python and install 3.4 which like a breeze
    with the default IDLE (which has autocompletion and synthax highlight and many goodies)
    Wrote this :

    from tkinter import *
    from tkinter import ttk
    root = Tk()
    ttk.Button(root, text="Olivier").grid()
    root.mainloop()

    Press run and I got a Window and button showing up in two seconds,
    I am not an expert or anything but, I mean come on! This is got to be way forward!

    ReplyDelete
  26. . Its a goddamn feature which is the reason they exist parallel to compiled language.
    Cool addicting games

    ReplyDelete