Comment 4 for bug 306427

[1]

Changing the coding style to use nerdyCaps is not a good idea
because the Storm code base itself uses lower_case_with_underscores.
We shouldn't fragment the formatting style.

Similarly, using 'my' in front of variable names is not a good idea
because it differs from the established coding style.

[2]

+We'll use "as S" to make typing easy, but still document that
+the new names we will be using are part of Storm.
+Some experienced programmers prefer "from storm.locals import *".

I don't find that using S. adds anything to the tutorial. In fact,
it's more confusing to me. Also, I don't think experienced Storm
developers use "from storm.locals import *", other than in the
interpreter when playing around.

I would prefer to see the tutorial changed to use qualified imports,
to make it clear where things come from. For example, we could
change this:

"""
Now we define a type with some properties describing the information
we're about to map.

{{{#!python
>>> class Person(object):
... __storm_table__ = "person"
... id = Int(primary=True)
... name = Unicode()

}}}
"""

to

"""
Now we define a type with some properties describing the information
we're about to map.

{{{#!python
from storm.locals import Int
from storm.locals import Unicode

>>> class Person(object):
... __storm_table__ = "person"
... id = Int(primary=True)
... name = Unicode()

}}}
"""

which at least makes it clear where Int and Unicode come from.

[3]

+In other cases, create_database() does not actually *create* a database. It would be
+more precise to say that it defines a connection to an existing database.

I don't think this really helps. Debating naming style in the
tutorial doesn't help. I would argue that the create_X naming
convention is well established as being about object creation, and
thus makes sense here.

I'm -1 on this branch.