Thank god for Google !!!

What in the world would any of us do without Google ?!?   Why we might have to begin thinking for ourselves were it not for Google…

Google Python Style Guide

Thank YOU Google !!!

I just hope Google someday gets around to saying things like, “…code reuse is a good thing…”.

Why does “crappy” code not perform worse than it seems to ?

I like good code like the next person however I am wondering why people spend so much time focusing on “crappy” code patterns that don’t seem to perform worse than expected ?!?

Here’s a thought:  If you want to complain about “crappy” code then why not fix all the crappy code you become aware of including all that stuff you cannot seem to understand !!!

Or maybe just realize the fact that your idea of “crappy” code may be another man’s treasure !!!   Oh wait, someone already thought of this when the following was coined, “…one man’s trash is another man’s treasure…”. Circa. 1570’s !!!

Or to put this another way…   those who feel some coding patterns may be “crappy” might just be limiting their own ability to perceive really useful code they would surely have overlooked !!!

I am NOT in favor of truly crappy code !!!

But, I am also NOT in favor of being so close-minded that I cannot see how useful alternative coding styles may be.

Single instances of “crappy” code cannot be crappy !!!

If you have to produce 1000’s or 1,000,000’s of iterations to see a performance problem from a single use chunk of code then there is very little reason to think about any such performance problem !!!

I might be impressed with those who rail against “crappy” code who also make darned sure all the code they can see in their field of vision is not also “crappy” code !!!

Scenario #1

For instance, consider the following pattern that was recently classified as being “crappy” by an intrepid band of hearty Python coders in an company we dare not name here…

This is “crappy” !

toks = ‘one two three four five six seven eight nine ten’.split()

This is not !

toks = [‘one’, ‘two’, ‘three’, ‘four’, ‘five’, ‘six’, ‘seven’, ‘eight’, ‘nine’, ‘ten’]

The crappy version was said to be “crappy” because the split was seen as being unnecessary because the non-crappy version was said to be the desired effect.

Those who said the crappy version was crappy have probably never had to load a list from a comma delimited jungle of data they may have had to spend several days entering manually by hand otherwise they may have gotten themselves some useful experience as to why the crappy version might be somewhat less crappy after-all.

Scenario #1 Benchmarks

I like benchmarks.  I like to know when code may perform badly at run-time at scale.

The crappy version for Scenario #1 runs 5x slower than the non-crappy version for 1,000 iterations.

The crappy version for Scenario #1 runs 7.6x slower than the non-crappy version for 10,000 iterations.

The crappy version for Scenario #1 runs 7.65x slower than the non-crappy version for 100,000 iterations.

The crappy version for Scenario #1 runs 7.66x slower than the non-crappy version for 1,000,000 iterations.

Um, if you turn-off the Python GC the performance issues seem to disappear for a while !!!  Just a thought…

Scenario #1 Analysis

The real question is this:  “Was the crappy code being used enough for the comments this code pattern elicited ?”  Probably not !!!

The justification for call the crappy version truly crappy was the performance concerns and there are some rather glaring performance concerns to be sure but ONLY when the crappy version was being used 1000 times more than it actually was being used.

Those who claimed the crappy version was “crappy” had to magnify the usage pattern by a minimum of 1000 times before the crappy version’s performance data might be measurable.

I agree the crappy version would be truly crappy if it were the actual source of some kind of measurable performance issue related to the loss of revenues or some other demonstrable effect that was actually causing some kind of problem.

The problem, as I saw it, had nothing to do with how crappy the code pattern may have been because let’s face it this is crappy code if it were to be used often enough for a problem to exist.

The problem, as I saw it, was a group of people all agreeing there was a problem where no problem really existed at-all simply because in their minds they were magnifying the problem by 1000 times just to be able to catch a glimpse of some kind of problem when there was no real problem at-all.

This piece of crappy code may have a real-world non-crappy use case that could have saved someone a lot of time, given the right set of circumstances related to having to maintain a huge data set by hand that had to be loaded into a list at run-time.  The desire to make this crappy-looking code non-crappy in a use case that could NEVER be actually measured as being crappy is the problem !!!  Far more time could have been spent entering all those commas and quote marks just to make the code less crappy than the effort would have been worth.

Why any person or group of people who are supposed to be intelligent talented software engineers would claim a harmless chunk of code was harmful given the actual use-case that existed in the actual source of the context for the original question which was related to a single use of the crappy version is well beyond my ability to comprehend in real terms.

The person who raised the issue was supposed to have more than 20+ yrs programming experience !!!  He found a single reference to the crappy version in a source file that was probably being used exactly once per iteration of some larger program.  WOW !!!  Talk about yelling “FIRE” in a crowded room !!!

The people who agreed with him were even more of a mystery because these people are supposed to be among the best and the brightest at this particular unnamed company and they went along with the idea that was raised by the one guy who should have known better than to yell “FIRE” in a crowded room.

It is interesting to note, these same people who were able to inflate a potentially crappy use-case beyond the original scope are the same people who are seemingly okay with all the following truly crappy coding patterns they seem to wish to do nothing about:

  • An Eager-loading ORM that maintains and uses exactly 1 Database Cursor per Session !!!
    • Why was this NEVER changed ???

I will stop here with the analysis because I think this one point bears further analysis.

How in the world do these crappy detecting software engineers allow an Eager-loading ORM to exist in the first place ???   And the company wants this sort of thing corrected !!!

I have to wonder about the skills these crappy detecting software engineers actually possess when they cannot find a way to remove the Eager-loading ORM in the first place !!!!

Removal of the Eager-loading ORM would be easy enough, for me to accomplish, but then I can tell the difference between crappy code that is really crappy versus crappy code that only seems to be crappy.

Well You See Timmy…

Now for the moral of this tale…

People who live in glass houses always seem overly eager to throw stones when their own houses have cracks in the walls so wide everyone knows there are problems.

I have no issues with people who can see imagined problems that don’t exist so long as they have their own houses in order but this was not the case in this instance.

These very same people, who seemed more than willing to detect crappy code patterns where there was no crappy code use case are the very same people who seem unwilling or unable to resolve glaring performance issues in a huge pile of code.

The rest of the issues these people could focus on are as follows:

  • mod_python rather than wsgi
  • Django not being used-all but then there is no discernible web framework being used at-all.
  • Eager-loading ORM – easy to resolve with Django.
  • Non-scalable Web App – because mod_python is being used rather than wsgi, for instance.
  • Development environment issues – all developers share a single instance of the run-time – each developer gets a different virtual host but all development being done in a single Linux instance.
    • Okay, this one truly baffles me !!!
    • How difficult can it be to get each developer their own Linux instance at a moment in time when everyone has a Cloud-based solution for doing this ?!?

Look, all these issues can be easily handled but none of them are being handled at-all.  Why ???

The reason(s) all these glaring issues are not being handled is easy… lack of experience and lack of skill in the developer community.

Nobody wants to make any real changes or nobody is able to make any real changes.

Dragging along ancient code from the deep past and then being either afraid to update it or unwilling to update it is more than ridiculous !!!

Solutions !!!

The solution for all this is also easy but very difficult to implement !!!

Rewrite your code every 18 months !!!

Better tools are being churned-out all the time.

Django is a proven Web Framework !!!

Wsgi is a proven technology stack !!!

Python+Django+tornado+wsgi+nginx equals a scalable Web App that scales as easy as you can build an automated process for spinning-up one more Linux Virtual Machine in the Cloud !!!

Or let’s put this another way…

Python+Django+tornado+wsgi+nginx was easy enough for me to handle all by my self – not that I might not have wanted to do this with a team of others – there just weren’t that many others I might have done this with.

The moment I achieved my first stable installation of Python+Django+tornado+wsgi+nginx I knew it was the way to go !!!

Python+Django runs as a separate wsgi web server with performance comparable to what you get from the Google App Engine, oddly enough, and “yes” I have run benchmarks that tell me this based on the data.

Tornado is a stand-alone Python-based Web Server with very good performance characteristics.

Tornado talks to an instance of a Python+Django web app via wsgi.

Nginx talks to an instance of Tornado that talks to an instance of a Python+Django web app via wsgi.

Why so many web servers in this stack ???

Why use Tornado at-all ???

I happen to know a little something I call Latency Decoupling that tends to make web pages serve much faster the more layers of web servers you use.

Nginx connected to many Tornado servers each connected to one or more wsgi Web Apps is far more efficient serving web content than Nginx connected directly to that very same wsgi web app.

Latency Decoupling kicks-in and your end-users have happy faces.

Ability to Scale the Web App also increases !!!

Many instance of the Web App within each Tornado instance !!!

Many Tornado instances within each Nginx instance !!!

Deployment gets easier !!!

Now with a single Python or Ant script you can spin-up yet another Amazon EC2 instance – connect-up the Nginx instances using a Load Balancer of some kind (nginx also does Load Balancing) and before you know it you have architected a really cool Django Cloud Solution that nobody else seems to have just yet.

Build a slick Control Panel for your Django Cloud Users and bingo you have the ability to grow a Web App from a single instance to any number just by clicking a button on a web page !!!

The only other detail would be how you monetize all this into something you can use to generate revenue.

All of this was easy enough to build when you have all the parts.

All of this should be easy enough for any company to use, if only they had I.T. staffers who had played around with these kinds of solutions but alas that seems to be lacking in most companies except for a few.

Too bad most would-be skilled programmers would tend to scoff at most of what’s written in this article as being some form of “crazy”… but then once upon a time the notion of generating electricity was also seen as being “crazy” along with the notion of gravity and quantum physics.  I can live with what others wish to say… so long as I get to build something really cool along the way.

Animal Kingdom Interview Sample

This comes right from an actual Interview Question with a major Fortune 100 Company and since I passed the interview process I shall not mention any names here…

Let’s just say for grins and giggles, I was more than able to whip-up the high-level view for this code on the whiteboard but then this is such a simple problem from an OOP perspective.

See the code here.

I was told many others did not respond correctly to this same question…

The code presented here work in Python 2.5 or Python 2.7 and probably for Python 2.4 since these versions are of the same general family.


Python Type-Cast the Easy Way !!!

Python objects hold key and value pairs – this is what every object holds, key and value pairs.

Python objects that have a __dict__ make it easy to convert the object from one class to another simply by replacing the old object instance with another as follows:

See the attached file with a sample of how this can be done most simply. (

There are other ways to accomplish the same goals using more elaborate means however this works using less code.

What to do when your objects do not implements the magic methods required for the aforementioned code sample ?

Easy, you can use method injection as described here or here or here or here.

It also helps to use a really good Python Debugger in the form of the Wing IDE.  Stare at the debugger while debugging Python code just long enough and sooner or later you may begin to see how to accomplish goals you may find useful.

I am not recommending you try using the aforementioned code as part of any professional solutions unless  you know who will be doing a Peer Review of your code but I am saying these techniques may be useful in learning something about the object types being used as to whether or not the object types are meaningful.

The point being, you can either grouse and lament how things cannot be done or you can learn the Agile Method for getting things done…

Why can human knowledge not be quantified ? And why do some people feel the need to try… ?!?

How much experience do you have using blah… ?!?

My response to this kind of query is generally… “A lot”… however saying you have a lot of experience does not seem to satisfy the questions for those who just have to think there is a way to quantify knowledge or experience.

The closest you will ever get to being able to measure human knowledge is…

You can measure how close to your own understanding someone else might be until… they end-up having more than you and then your ability to measure falls apart.

You can make people play guessing games to see if they know some things you think you know but again, the moment the person you want to measure has more than the one doing the measuring the process fails to please.

You cannot measure human intuition…

The ability to reach outside the box cannot be measured.

The ability to do more with one’s mind than has been done in the past cannot be measured.

I have interviewed with some hiring managers who said up-front they did not want anyone who had any kind of intuition…

I have to wonder about anyone who claims to be agains the use of human intuition just because… well my pets won’t be intuitive but they are animals… humans should use intuition because they can… simple as that.

Get over it gang, human knowledge cannot be measured any more than human experience can be measured.

Anyway, I prefer to take myself out of the equation when trying to determine what level of experience someone might have, were I the one faced with trying to staff some kind of software project.

It’s just too easy to become so self-deluded to feel as-though everyone sees it the way I do so as to render oneself so incredibly silly-stupid as to make the process of trying to make the determination useless.

If we all just focus on what the technologies we work with can do and then figure out what these technologies should do and then work on how to make these technologies do what they were not designed to do we might all learn enough to be useful.

Far too many people like to focus only on what the docs say these technologies can do and nothing more.

Python tuples are immutable

Yeah, until you learn how to change the contents of a tuple and then you figure-out there almost no such thing in Python as an immutable Constant other than the mere conceptualization of what immutable might mean so long as you really didn’t want something that is actually immutable and really unchangeable – but again, I might think my windows on the front of my home are immutable so long as nobody ever figure-out how to pick up a rock… in real terms I just cannot be that stupid as to really think, for any period of time, that my windows at home are any more immutable than Python tuples – cuz they are NOT.  Windows can be broken and Python tuples can be modified… rocks and lists were all made to resolve these issues.  On the other hand, I also don’t let just everyone know where I live either… and I don’t leave any loose rocks laying around my front yard.  Immutable is not always immutable… and constants are not always all that constant – at least where Python is concerned.

Sorry Google but when you want to talk to me abut Python you might give some thought to just how many hours I have spent using Python to solve real problems… and “yes” I too read where tuples are immutable but… that’s all the farther that one goes because I happen to know there’s almost no such thing in Python as a Constant where Constant really means “…it can’t be changed…” and by “…can’t be changed…” I mean “…it really cannot be changed…” and by this I mean “…it really cannot be changed because the freaking runtime keeps it from being changed…”.  Talk to me about immutable in Python when there is really no way to make Python change the value of the thing you wish me to think is “immutable”.  Darn, then you learn anyone can code a Python extension that gets a pointer to that pesky immutable variable with the evil intent to make a change without the consent of the Python runtime.  Oops !!!   Hey, maybe I just know Python better than you thought… OR… I am able to see how to get things done when everyone else says it ain’t possible.  Either way, I want to do it more when Google tells me I should not… maybe this has something to do with how one ends-up rebelling against one’s parents… or maybe Google simply wants to take control over how we use Python… either way… whenever I am told it’s not possible I tend to look for ways to make it possible – doing this helps me learn and learning is good.  LOL


What does Google think about Python ?!?

Earlier today I had the opportunity to speak with someone from Google who shared these thoughts with me in regard to Python…

  • Python tuple objects are immutable.
    • Tuple objects lack the methods that allow elements of a tuple to be modified however… tuple objects can be recast into lists, list objects are not so immutable, after the change has been made the lists can be recast as tuples, as follows:
      • x = (1,2) # x is a tuple
      • try:
      •     x[0] = 11 # this throws an error
      • exception:
      •     print ‘Error Will Robinson…’
      • x = list(x) # now x is a list
      • x[0] = 11 # this will not throw an error
      • x = tuple(x) # x is now a tuple once again
    • Obviously the guy from Google who thinks he knows Python failed to understand this one simple thing about tuple objects – “tuples were made to be cast as lists”.
      • Python tuple objects are as immutable as your typical window pane is not breakable… so long as you “think” your typical window pane cannot be broken and nobody ever picks-up a rock you are right… however… rocks were made to be thrown by people who have hands.
      • The fact is… there are no objects in Python that are truly immutable however tuple objects lack the methods that allow tuple members to be changed unless one recasts a tuple as a list and then back again after one makes the desired changes.
    • Additionally, one could create a tuple subclass that allows tuple members to be modified.
  • When a global variable is assigned a tuple it is not possible to make any changes to that global variable.
    • This is just False !!!
      • There is NOTHING special about variables that hold onto tuple object instances.
    • It is possible to make Constants using Python however this does not come with Python’s Standard Library.
      • Tuples are NOT Constants !!!
        • Variables that hold onto tuple pointers are NOT Constants !!!
      • Not even a Python Constant will be truly immutable even when a Global Variable is used to point to the Instance of a Python Constant.
        • The only way to make a Global or Static Variable in Python capable of being truly immutable is to place that Constant into a Module that lacks the ability to allow the Constant to be changed at runtime.
        • Your typical Python Global Variable can be changed, which is to say your typical Global Variable is Read-Write and can be assigned to a different value that can be a different Instance of a Python object.
  • The special thing about inheritance is multiple inheritance.
    • One man’s special is another man’s who-cares ?!?
    • Apparently even Google’s Search Engine does not even know “what is special about python inheritance“… LOL
      • You might think something “special” about Python might be clearly special to everybody however this is just NOTthe case in this instance…
        • Is it any wonder I might not know this specific aspect when, it seems, not enough other people do know about it to make it to the first page of a Google search… ROFL
          • On the other hand, not even this Google guy was aware of how special this aspect of Python was to himself but then we can all hold things close to our own hearts without getting approval from the rest of the world…

I was disappointed in how little this one guy from Google seems to know about Python OR maybe I just dug deeper into Python than Google has…


Maybe this Google guy think only hackers play-around with Python to the point of knowing the language inside and out and maybe this Google guy is only able to use Python in the most superficial way possible. ?!?

The great thing about computers is Computer Science… we can all test our assumptions to see whether or not our assumptions are correct or as-correct as we with them to be.

Also it’s refreshing to me to realize how human this one Google Guy is because he is not immune from wishful thinking where Python is concerned.  He “wishes” Python was a much better language than it is.  He “wishes” tuples are actually as immutable as he “wishes” them to be even though the language does not support his wishes, he continues to harbor his fanciful wishes.  This speaks well of his inner-child…

I like to stick with the Science… the way Python actually works… devoid of my own wishful thinking… Python tuples are no more immutable than my nose is unable to be cut off… I prefer to leave my nose intact just as one would have to prefer to leave a tuple instance unchanged but not because a tuple CANNOT be changed, just that one prefers a tuple to be immutable.

Try it for yourself and you be the judge !!!

Android-based Interactive Multimedia Presentation Builder and Player – Looking for Investors

Android-based Interactive Multimedia Presentation Builder and Player – Looking for Investors

Learn More…

Downloads to be made available soon… Stay tuned.



%d bloggers like this: