Mike and James and all, I'm going to need to put off the Python pairing/lessons until after OSCON. Sometime after July 26th.
Ingy On Wed, Jul 8, 2009 at 11:27 AM, Ingy dot Net <[email protected]> wrote: > Thanks Mike. I'll be sure to read all this stuff before we meet up next > week. > > -Ingy > > > On Tue, Jul 7, 2009 at 6:09 PM, Mike Orr <[email protected]> wrote: > >> On Tue, Jul 7, 2009 at 1:35 PM, Ingy dot Net<[email protected]> wrote: >> >> > 0) Primarily want a code review of what I have on >> > http://github.com/ingydotnet/testml-py/ >> >> I can look at that later. >> >> > 1) Runtime introspection - there is all kinds of things I'm having >> trouble >> > finding at runtime. Like maybe I want to know what the file path is of >> the >> > current python module that py.test is executing for me. >> >> If you mean, "What is the path of the currently-executing module?", >> that's ``__file__``. >> > >> >> Also note ``__name__``, which is the module's fully-qualified name (or >> "__main__" if the file was run directly as a script). >> >> Imported modules are cached in sys.modules as {'name': <module>}. You >> can inspect the module object for metainfo. >> >> > 1b) Stack trace introspection. >> >> That gets into a specialized area of Python which most people don't >> do. You can raise a bogus exception and assign the traceback to a >> variable. From there the ``inspect`` module might help, as well as >> your old friends str(e), repr(e), dir(e), vars(e), and help(e). >> >> http://docs.python.org/library/inspect.html >> (See especially the "interpreter stack" section) >> >> > 2) Popular idioms. I get the feeling that try/except usage is much more >> > common than in Perl. >> >> try/except provides a way to isolate error code, little-used code, or >> out-of-band code. It can also be (ab)used to provide an alternate >> return value if the function has special cases. There's no speed >> penalty for try if no exception is raised. >> >> The main difference between 'if' and 'try' is that 'if' suggests that >> any branch might be taken in a normal case, while 'except' suggests >> that this branch should rarely if ever happen. Of course, you can't >> be 100% strict on this. It might be more elegent to have an >> 'if/elif/elif/else' where the 'else' should never happen. Conversely, >> you may be forced to use 'try' because a third-party function raises >> an exception. >> >> Also note the differences between the exceptions. >> 'ValueError': a function argument has the right type but an illegal value. >> 'TypeError': a function argument contains a more serious error than >> ValueError, or a >> variable unexpectedly has the wrong type. >> 'AssertionError': two parts of your own code appear to be >> inconsistent. E.g., if one >> routine builds a data structure and another routine reads it, or >> if a variable that >> should have been set is unexpectedly None. Useful in an 'else' >> that should never >> happen. Not normally used for function argument errors, or for errors >> in >> third-party code. >> 'NotImplementedError': a good stub for functions that haven't been >> written, for >> superclass methods that must be overridden, or to ensure that >> destructive code >> doesn't get executed during development. >> 'EnvironmentError': something is wrong in the runtime environment. >> This could be >> used for missing files or environment variables, unavailable >> servers, invalid >> configuration, etc. However, there are no standard rules for >> which exceptions to >> raise in these cases. You could ignore the condition and let >> third-party code raise >> OSError, KeyError, etc. However, this may confuse the user, >> especially if the >> error message is imprecise. >> 'RuntimeError': specifically means miscellaneous error, something that >> has no better >> category. Useful for temporary situations during development, >> especially to >> inspect live code under pdb. Some people also use it for >> environment/configuration >> errors in the top-level script. >> >> There are other idioms but I can't think of them off the top of my >> head. Remember that subscripting and ranges are open at the right >> end, so that ``range(5)`` goes 0 to 4, and ``lis[1:3]`` gets elements >> 1 and 2. >> >> When setting default values for functions, never use a mutable value: >> >> def func(lis=[], dic={}) # Bad >> >> The same list and dict will be shared across all calls to the >> function, which will royally confuse users. Instead use a dummy >> immutable value such as None: >> >> def func(lis=None): >> if lis is None: >> lis = [] >> >> > 3) Accessing global variables across modules. I spent 2 hours yesterday >> on >> > this, and still feel clueless. >> >> They are attributes of the module object. So first get the module via >> import or an argument or sys.modules. Then use dotted notation if you >> know the name of the variable beforehand, or getattr() if you're not >> sure it exists or have to calcuate the name. You can also call >> vars(m) to get the globals in dict form, but this is read-only. >> >> > 4) How the popular python test frameworks work. >> >> I'm not an expert on this but we can discuss it in person. Nose is >> the fastest-growing test framework. The others are unittest and >> py.test. There are several other test frameworks specific to web >> applications, but I don't know if you're interested in that. >> >> > 5) Module installation and distribution best practices. >> >> There are currently two overlapping conventions for this. "distutils" >> is built into Python and revolves around a setup.py file in the >> package. Users can download the package manually, unpack it, and run >> "python setup.py install". The distutils conventions are sufficient >> for small packages. >> >> http://docs.python.org/library/distutils.html >> http://docs.python.org/distutils/index.html#distutils-index >> http://docs.python.org/install/index.html#install-index >> >> "setuptools" is a superset of distutils with more features, both in >> the setup.py and in the installation procedure. "easy_install" comes >> with setuptools, which can download and install a package in one step. >> Larger packages may need setuptools' features and convenience >> functions. Setuptools is not built into Python so you have to install >> it separately. >> >> http://peak.telecommunity.com/ >> (See the links under the third entry dated Friday, September 16, 2005) >> >> "pip" is an alternative to "easy_install". It's more modern but has >> had less use and testing. Due to bootstrapping issues, you have to >> manually install setuptools first, then "easy_install pip", and then >> you can "pip install" everything else. Pip creates a slightly >> different directory structure than easy_install, one that's preferred >> by pip fans and is closer to the traditional Python structure. >> >> http://pypi.python.org/pypi/pip >> >> Any of these installation methods can be used on any package, no >> matter which one it was built for. The only caveat is that if the >> setup.py depends on setuptools features, the user will have had to >> install setuptools beforehand, or else the application developer will >> have had to put a trick into setup.py to auto-download setuptools. >> >> "virtualenv" creates an isolated Python runtime environment, into >> which you can install packages that won't be seen outside the >> environment. This is useful if you have two programs that need >> conflicting library versions, or to create a test environment that can >> be blown away and recreated easily. Virtualenv installs Setuptools in >> the environment automatically, so that's one less step to do. >> >> http://pypi.python.org/pypi/virtualenv >> >> "virtualenvwrapper" is a set of command-line utilities for virtualenv. >> It depends on Bash, so it doesn't work on Windows. >> >> http://pypi.python.org/pypi/virtualenvwrapper/1.18 >> >> "buildout" (officially "zc.buildout") is a way to make a repeatable >> custom environment, such as for a server farm. Its functionality >> overlaps with virtualenv, but it does it in a different way. Some >> people find its configuration file harder to understand. Buildout is >> more often used to create a deployment configuration for a finished >> product, than for interactively trying out libraries during >> development. Interestingly, buildout can be used within a virtualenv. >> >> http://pypi.python.org/pypi/zc.buildout >> >> -- >> Mike Orr <[email protected]> >> > >
