Python, from a PHP Perspective

Recently, I began a side-project using web.py and Python 3 with PyCharm as my IDE.  It's been largely successful in terms of transitioning from PHP to Python with respect to the language.  Still a little fuzzy on dictionaries vs. objects, but I'm slowly getting there.

I've been actively developing in PHP now for over a decade.  I consider myself an expert in PHP and have written some extremely complex applications including an event-based framework for mongoDB and MySQL that's (data) template-driven and complete with a full-suite of micro-services.

I took a couple of online courses, or at least tried to, in Python and immediately started hitting roadblocks.  One course wanted us to do everything through something called Jupiter which was, as far as I was concerned, a layer of janky obfuscation over the core language. Class.dropped() after a couple weeks because I spent more time fighting with the interface than I did the language.

I tried another class, from stackSkills, and this one was way more successful.  I've been immersed in writing a private, social-media site using web.py as the framework.  It's been a learning experience and I've been mostly successful.

Django lets you write web apps in Django. TurboGears lets you write web apps in TurboGears. Web.py lets you write web apps in Python.
— Adam Atlas

 

Things that drive me nuts about Python

  • Version 2 or version 3

When you install Python you get both versions: country and western.  Sorry.  Version 2.7 and version 3.5.  As a newcomer, I have no idea what the difference is between the two, but my first thought was that perhaps version 3 was experimental...  then I learn that version 2.x is still supported because there's apparently a lot of apps/developers that refuse to upgrade.

Kind of like what windows went through the first couple decades supporting the 64K block boundaries making everything suck until Microsoft finally said "enough" and joined the rest of the world in embracing 32 and 64-bit architectures.  

Well, Python is the same way.  For the most part, I've ignored everything not 3.x as a work-around.  But it's still a pain when you're doing something with pip or from the command line and you invoke the wrong version.

From what I understand, the main reason why Python 2.7 still exists is that not all of the packages have been upgraded to support Python 3.x.  (Which I can personally and painfully confirm.)

I think it be high-time that the Python wonks commit to the latest version and deprecate 2.x, including libraries that don't support 3.x.  More than five years of this childish bullpuckey is more than enough.  Strap on your big-boy pants and get 'er done!

  • pip modules

In my experience, limited as it may be, this is the most janky thing about python yet simultaneously, one of the best.  Python thrives on modules, or packages.  You can install a module from the extensive library using the pip utility and then you're off and running.  There's literally a library for everything.

What makes it janky is that when it doesn't work, it does so with kind of a snooty aplomb providing minimal feedback about why it refused to install.

For example, I've spent days trying to figure out how to capture a screen shot of a URL submitted by a user so that I can create a thumb and embed the image in the home feed.  Easy right?  (It is super-easy (one level above trivial) in PHP.)  

Python, not so much:

Isn't that a helpful error message?  Apparently, I can't install a stock library/package/module because there's not a distro that matches my current release version of Python.  (Kind of reminds me of how you have to update the Version field in the TOC file for LUA add-ons for WoW for every patch release...)

So, since I can;t install the package as a user via the IDE, I'll try from the command line as root...

root@agador-spartacus:~# pip3 install pyqt4
Collecting pyqt4
  Could not find a version that satisfies the requirement pyqt4 (from versions: )
No matching distribution found for pyqt4

Best I can figure is that the package is just too old for my release.  (Then why show it in the pick-list in the IDE?!?)  Installing pyqt5 was successful, but it doesn't have the backward compatibility I needed to make the API calls that was documented in the example.
 

  • New Versions of Packages Lack Backward Compatibility

So, even though I was successfully able to install pyqt5, I couldn't follow the how-to on completing the task because of the gaping holes in the backwards compatibility.    

According to the example, I had to include the necessary package modules thus:

from PyQt4.QtCore import *
from PyQt4.QtGui import *
from PyQt4.QtWebKit import *

Which became impossible using the Qt5 version simply because one of the modules (I think it was WebKit) no longer exists on that library. 

Sorry about your luck, chuck, eh?

  • Dummy Packages

Checkout the dns package.  It's available.  One would think that it's a great package to help manage DNS resolution, right?

Nope.  It's empty.  The package contains only some XML that defines the package at 1.0 and is otherwise empty.  But it's there in the PyPi repository and you can try to install it all day if your thing is looking at pip error messages.

  • Distribution is a Pain

Hey Python wonks.... you desperately need something similar to PHP's composer.  I am dreading the day when I have to deploy this application to AWS.  Why?  Because there was, not including web.py itself, around a dozen or so packages that I added to the standard version.

Yesterday, I upgraded my development laptop from Ubuntu 14.04 to Ubuntu-gnome 16.04 and, in doing so, lost my Python module history.

In PHP, this would be a non event.  Simply reinstall composer and pull down the required libraries and done.

Not so much in Python.  I had to continuously start the framework enjoying the one error-message-at-a-time before aborting telling me which module was missing... stop, install the module, then go on.

Seriously, the only reason hardcore Python devs aren't screaming for a composer-like tool is because they've never used one.

  • Root vs. User vs. VirtualEnv

Just in case installing packages wasn't confusing enough, once you've limped past the python version, staggered past the pip limitations, you finally arrive at where the modules should be installed.  You have choices, three:

root -- installs a package presumably available to all users.  I use this option when installing as  user completely fails (permissions, usually) and I use this option a frightening amount.

user -- installs a package available to the current user.

VirtualEnv -- creates something called a virtualEnv which, I assume, installs the package local to the current project which, excuse me, should the only way you should be able to install packages.  (If they can get integrated into git and if they can be automagically kept current somehow -- you know, how like composer works...)

Summary

I'm sorry if this post ruffled your feathers.  Well, not really.  I think Python is an awesome language and the package system is incredible if not optimally or elegantly implemented.

  • Drop Python 2.7 -- yes, there will be gnashing of teeth and rending of garments but, but the end of the effort, we'll all be on a unified platform swaying and singing Kum-ba-yah or whatever.
  • Classification of Packages by Release -- if I can't install a package because my up-to-date version of Python prevents it, then simply tell me so.  Your error message obfuscates the reason why the installation failed.  If I'm pulling new packages via my IDE, then don't list packages that aren't compatible (or available).
  • The PyPi repo needs an enema to clean out empty or deprecated packages which only serve to  waste developer time.
  • Packages should be by installed by project only.  Hard disk space is cheap.  Get over it.
  • Get a Composer-like tool or do some good and port composer to Python.  It makes application distribution a non-event and keeps your packages current, all your packages, with a single command.  How can you not want this?

I am starting to really enjoy Python and I am sure, in another decade, when I am an old-salt in Python like I am in PHP, then I will look back at this post as either being completely full of excrement or an acknowledgment of the state of the language "in the old days" before they developed better tools.