Month: November 2015

Cannot power off or reset virtual machine in vSphere

Posted on Updated on

Had a vm that after a reboot would not come up.

Tried to do a reset and then the reset just hung there for a long time.

I logged on the host bypassing vsphere and the power off command wouldn’t work since another task was in progress.

then I ssh’d into the host, getting the vmid tried to kill it with command  vim-cmd /vmsvc/ VMID#

which gave me “power off failed”


As a last resort I thought I would have to vacate the host and restart it.


Then I noticed  that I had the thick client at another workstation hosting an ISO to the vm. Reason: the vm and host were remote so I wanted to feed the iso local to the vm via client connected iso.

So I terminated the viclient on the remote site, and my vm eventually came back.

something so simple yet probably overlooked often.


Find what SQL server features and components are installed

Posted on Updated on

There is a feature in SQL installer that can tell you what you have installed

Check your install media or SQL Server Installation Center if it is installed locally, then run the link for “Installed SQL Server features discovery report”.





Thanks to:

Can you edit a character in a string ?How do you change a string in python?

Posted on

Can you edit a character in a string ?How do you change a string in python?

If p=”nice”

how do I make “nice” into “Nice” ?

The answer is that strings are immutable, meaning they cant be changed.

so you would need to assign p to a a new string


cannot do p[0]=’N’

Google app engine : Viewing the different versions of your app

Posted on Updated on

your app is

you can view different versions of your app by adding versionnumber and dash in front of that

example: (URLs aren’t mean to work)

my example project url is:

i can view both version 1 and version 2

to view version 1 it would be

to view version 2 it would be


Google App Engine : when connecting to http://localhost:8080 get HTTP Error 500 Internal server error

Posted on Updated on

So I was running google app engine in order to get some code running.

while it should have ran out of the box it didn’t.

Checked firewall, which would have been my first suspect.

that wasn’t it.

http://localhost:8000 was working fine.

Looked around and found the solution below:

had the same problem. This seemed to fix it:

cd to google_appengine, run

python –port=8080 –host= /path/to/application

at this point there is a prompt to allow updates on running, I said Yes.

At this point the app was running as it should, also when I quit this and went in using the launcher again, that worked too.

Once I ran the command it was able to give me feedback on my code via error messages that  I wasnt getting with GAE. And it’s always something simple….

Format Python code correctly the Google way!

Posted on Updated on

This style guide from google can help clean up your code and bring you up to speed on sharing your work with others and easily understanding other’s work


Python is the main scripting language used at Google. This style guide is a list of dos and don’ts for Python programs.


Python Language Rules


Run pylint over your code.


Use imports for packages and modules only.


Import each module using the full pathname location of the module.


Exceptions are allowed but must be used carefully.

Global variables

Avoid global variables.

Nested/Local/Inner Classes and Functions

Nested/local/inner classes and functions are fine.

List Comprehensions

Okay to use for simple cases.

Default Iterators and Operators

Use default iterators and operators for types that support them, like lists, dictionaries, and files.


Use generators as needed.

Lambda Functions

Okay for one-liners.

Conditional Expressions

Okay for one-liners.

Default Argument Values

Okay in most cases.


Use properties for accessing or setting data where you would normally have used simple, lightweight accessor or setter methods.

True/False evaluations

Use the “implicit” false if at all possible.

Deprecated Language Features

Use string methods instead of the string module where possible. Use function call syntax instead of apply. Use list comprehensions and for loops instead of filter and map when the function argument would have been an inlined lambda anyway. Use for loops instead of reduce.

Lexical Scoping

Okay to use.

Function and Method Decorators

Use decorators judiciously when there is a clear advantage.


Do not rely on the atomicity of built-in types.

Power Features

Avoid these features.

Python Style Rules


Do not terminate your lines with semi-colons and do not use semi-colons to put two commands on the same line.

Line length

Maximum line length is 80 characters.


Use parentheses sparingly.


Indent your code blocks with 4 spaces.

Blank Lines

Two blank lines between top-level definitions, one blank line between method definitions.


Follow standard typographic rules for the use of spaces around punctuation.

Shebang Line

Most .py files do not need to start with a #! line. Start the main file of a program with #!/usr/bin/python with an optional single digit 2 or 3 suffix per PEP-394.


Be sure to use the right style for module, function, method and in-line comments.


If a class inherits from no other base classes, explicitly inherit from object. This also applies to nested classes.


Use the format method or the % operator for formatting strings, even when the parameters are all strings. Use your best judgement to decide between + and % (or format) though.

Files and Sockets

Explicitly close files and sockets when done with them.

TODO Comments

Use TODO comments for code that is temporary, a short-term solution, or good-enough but not perfect.

Imports formatting

Imports should be on separate lines.


Generally only one statement per line.

Access Control

If an accessor function would be trivial you should use public variables instead of accessor functions to avoid the extra cost of function calls in Python. When more functionality is added you can use property to keep the syntax consistent.


module_name, package_name, ClassName, method_name, ExceptionName, function_name, GLOBAL_CONSTANT_NAME, global_var_name, instance_var_name, function_parameter_name, local_var_name.


Even a file meant to be used as a script should be importable and a mere import should not have the side effect of executing the script’s main functionality. The main functionality should be in a main() function.

Parting Words


If you’re editing code, take a few minutes to look at the code around you and determine its style. If they use spaces around all their arithmetic operators, you should too. If their comments have little boxes of hash marks around them, make your comments have little boxes of hash marks around them too.

The point of having style guidelines is to have a common vocabulary of coding so people can concentrate on what you’re saying rather than on how you’re saying it. We present global style rules here so people know the vocabulary, but local style is also important. If code you add to a file looks drastically different from the existing code around it, it throws readers out of their rhythm when they go to read it. Avoid this.

easy_install vs pip : what to use?

Posted on Updated on

Nice answer over at stackoverflow

Many of the answers here are out of date for 2015 (although the accepted one is not). Here’s the current state of things:

  • Binary packages are now distributed as wheels (.whl files)—not just on PyPI, but in third-party repositories like Christoph Gohlke’s Extension Packages for Windows. pip can handle wheels; easy_install cannot.
  • Virtual environments (which come built-in with 3.4, or can be added to 2.6+/3.1+ with virtualenv) have become a very important and prominent tool (and recommended in the official docs); they include pip out of the box, but don’t even work properly with easy_install.
  • The distribute package that included easy_install is no longer maintained. Its improvements over setuptools got merged back into setuptools. Trying to install distribute will just install setuptools instead.
  • easy_install itself is only quasi-maintained.
  • All of the cases where pip used to be inferior to easy_install—installing from an unpacked source tree, from a DVCS repo, etc.—are long-gone; you can pip install ., pip install git+https://.
  • pip comes with the official Python 2.7 and 3.4+ packages from, and a pip bootstrap is included by default if you build from source.
  • The various incomplete bits of documentation on installing, using, and building packages have been replaced by the Python Packaging User Guide. Python’s own documentation on Installing Python Modules now defers to this user guide, and explicitly calls out pip as “the preferred installer program”.
  • Other new features have been added to pip over the years that will never be in easy_install. For example, pip makes it easy to clone your site-packages by building a requirements file and then installing it with a single command on each side. Or to convert your requirements file to a local repo to use for in-house development. And so on.

The only good reason that I know of to use easy_install in 2015 is the special case of using Apple’s pre-installed Python versions with OS X 10.5-10.8. Since 10.5, Apple has included easy_install, but as of 10.10 they still don’t include pip. With 10.9+, you should still just use, but for 10.5-10.8, this has some problems, so it’s easier to sudo easy_install pip. (In general, easy_install pip is a bad idea; it’s only for OS X 10.5-10.8 that you want to do this.) Also, 10.5-10.8 include readline in a way that easy_install knows how to kludge around but pip doesn’t, so you also want to sudo easy_install readline if you want to upgrade that.

from abernet