def setPubyear(self,year):
    self.pubyear = year
  
  def getPubyear(self):
    return self.pubyear

The reason you're taught (and I, too, teach) the use of methods rather than direct variable access is because it gives you a far greater flexibility later on. Hard coding variable names within objects into applications makes those variables a part of the API (Application Program Interface) and the provider of the class is then constrained in future enhancements. And that's a double constraint, because there's no intermediate code layer in which features that may become necessary (capitalisation, space trimming, logging access etc) can be added. In other words - by directly accessing variables, you're building up a potential update and maintenance problem.

But wouldn't it be nice in the application to be able to access properties / attributes of an object as if they were simple variables, rather than having to use the extended syntax of calling setter and getter methods? Well - in Python you can, using a property. Here's how it works:

• within your class, you declare that variable name = property (getter, setter, deleter, doc) where getter, setter and deleter are the methods to run when a property is called up. You'll always need to provide a getter (otherwise there's little point in trying to define a property), but the other parameters are optional.

• within your application, you access the property as if it was a variable within the object, but within the class it gets diverted to the code.

Example:

Defining a property:
  author = property(lambda x:x._author , None)

Making use of that property:
  print nineteen.author

Complete example - [here] from the course I've been giving in Oxford for the last couple of days. And that gives me an excuse to illustrate my post with a picture I took when walking into the location at which I was training along the River Thames

One loo, one showerroom between three rooms (the 4th in en Suite). And when I took a shower, I noted:

* No loo in the bathroom.

* Going to the separate loo on the way to the bathroom... no hooks or table to put towel/clothes on while using loo - had to use floor.

* A shared shower mat for all guests

* Toilet and shower room doors bolt from inside, with no outside indication if they're engaged or not

* Black mould in the shower

* Shower head very loose - you have to jiggle with it when the water's on to get it to play over you rather than down the wall.

+ Good water flow, hot water, came through almost instantly too

And looking wider

* Thin walls

* Fire safety sign on floor, under fire extinguisher, wedged in by bookcase

* No checkin to check address / gather any needed legal deatails

* Not matching hangers in wardrobe

* Fire door and automatic closer on bedroom but carpet pile stops the door closing automatically, and it must be dragged

* Single tiny cereal packet at breakfast - then the basket's taken away. Single butter pat. Nice butter, mind you.

* Lots of doors marked "private". No "knock for help" or call bell. A mobile phone number to call "if you need to reach us".

* "BBE July 2012" says the marmalade - in May 2013

+ Strong WiFi connection / easy connection (benchmarked to a tenth of what we have at Well House Manor, but it met my needs!)

+ Efficient payment - took my 50 pounds quickly by modern credit card machine

In summary... I can put up with a lot of the limitations if made to feel welcome - but here I felt that my primary purpose was to provide an income. So much could be done at so little outlay... but then they were full, so why bother - there will be plenty more mugs along to pay them their fifty quid.

  >>> a = [10]
  >>> b = [10]
  >>> c = a
  >>> a == b
  True
  >>> a is b
  False
  >>> a is c
  True
  >>>

a and b are different lists, but they contain identical information. c is another name for the list which is also called a.

The == operator tells you whether two variables (or expressions) contain equal values, whether or not they're the same actual object.

The is operator tells you whether two variable names point to the same object.

A list (as used above) is a mutable object - something that can be changed within itself. Integers, floats, strings and tuples are immutable - in other words if you want to change something, you need to create a new replacement object. And in Python, identical immutable objects are stored only once for efficiency - so you'll find a different set of results from using is ... if two immutable objects are identical, they'll be the same object. Thus:

  >>> a = 10
  >>> b = 10
  >>> c = a
  >>> a == b
  True
  >>> a is b
  True
  >>> a is c
  True
  >>>

So - what are the issues that have changed?

Firstly, I prefer en-suite. Now I knew this was not when I booked it, but I still expected a wash basin in the room. Tough, there isn't one. And - worse - the single shared loo doesn't have a washbasin either; the only wash and water available is in the single shared bathroom shower room.

Secondly, I like a bit of space. This room's a single. And it's a single because that's all that could fit between the door and the wall. There's no room for a bedside table, so in order to put something aside, it's down to the floor or up and across to the little "dresser/desk" which is very suitable for smaller people.

Thirdly, I welcome a welcome tray and, yes there is one (queue for water at the shower room). And I would love to be able to plug it in. I'm able to do so, provided that I unplug either my laptop or the TV, but the kettle must remain and boil on the floor because the built-in cable isn't long enough to reach up to the dresser.

Fourthly, the description of the location is "Oxford". Postal address, maybe but it turns out that it's on a very long street and is beyond even the ring road. Bit of an issue as I left my car where I'm working and walked here due to the traffic issues of the City. An enquiry of where there's a nearby place to eat tells me to go to Summertown - that's a mile and a half, and advises me to get the bus if I don't want to walk.

Fifthly, the welcome was "a la seaside landlady". Not "did you have a good journey", but "I'm glad you got here [at last] because we're going out". And that was at around 18:30, when I had booked for arrival between 18:00 and 19:00.

In the 1990s, this would have been fine - the sort of place where First Alternative delegates used to stay when I was training for them in Harwell. But times have moved on, everyone (or nearly everyone) has upped their game and although it's clean (and does offer WiFi) it's fallen behind - and behind to the degree of being "sorry - I wouldn't stay again".

The price I'm paying? The same as I paid for a hotel about half a mile from Paddington station last week, which overlooked a London Square and was just round the corner to Bayswater. And that was en-suite. Mind you - the London place is exceedingly good value!

When you're writing code, you should be thinking of your user. That may be your end user or - if you're writing a module or classes - that might be a fellow developer, set of developers or even yourself. Whichever it is, the important thing is to get it right for them. It needs to be well specified, robust, well tested - and that's why you're encouraged to use Test Driven Development.

Writing the tests first helps you ensure that you're providing the right product. It helps you ensure that each of the elements work. And it lets you use testing tools which allow you to build up, rerun and retest time and time again with correlated results. How many times have I written code, come back to it years later and added something in the process breaking an obscure but important feature? With test driven development, and unit test tools, I can now build up test procedures and have an ever-growing validation set. That way, features won't get left behind.

Python coding has always encouraged redientary testing with
  if __name__ == "__main__":
but we can now go further - and we did on yesterday's Intermediate Python course.

My first test code is [here]. It's a simple exercise of an object, with the user having to check the results and ensure that they're as expected.

I extended that [here], testing multiple objects - but still a manual look through the results to ask "was that OK?"

Using unittest [here], I ran a series of tests and they come out with a neat report to show how they've done and

finally [here] I ran a series of tests in severl test groups. And indeed I can keep adding if I wish.

With all working tests, the final results are as short as

  munchkin:yi grahamellis$ python tdd_3
  .....
  ----------------------------------------------------------------------
  Ran 5 tests in 0.001s
  
  OK
  munchkin:yi grahamellis$

which is really all I need.

With a failed test, you get a need log telling you where the issue lies:

  munchkin:yi grahamellis$ python tdd_3
  F....
  ======================================================================
  FAIL: testfinish (__main__.TestBusFunctions)
  ----------------------------------------------------------------------
  Traceback (most recent call last):
    File "tdd_3", line 61, in testfinish
      self.assertEqual(gam,"08:28")
  AssertionError: '08:27' != '08:28'
  
  ----------------------------------------------------------------------
  Ran 5 tests in 0.001s
  
  FAILED (failures=1)
  munchkin:yi grahamellis$

The sample class I was testing through these examples is [here]. You'll note that it's independent of the tests in that there's noting at all that changes in the class for it to be run under the test harness.

The objective was to provide an almost-trivial way of letting results be viewed via a remote browser. No forms, no validation needed, no formatting of the plain text output. I used the oldfashioned common gateway interface.

My script starts:

  #!/usr/bin/env python
  print "Content-type: text/html\n"

And that's to tell the Apache httpd web server that the script is written in Python, and that the output is HTML.

You also need to enable CGI in your httpd.conf file (or a file it includes) and set the file to be executable.

In order to have the code that normally prints the results to file / stdout in a fixed width font, you'll want to put it within a preformatted style, or <pre> tag pair.

  print "<pre>"
  Output code goes here
  print "</pre>"

Some elements of note:

a) Progress logging to stderr:

  tracey = sys.stderr

and

  percent = 100.0 * counter / totalwork
  report = "Here we go ... {:8.2f}% of the way\r".format(percent)
  tracey.write(report)
  tracey.flush()

in my code. The output's to stderr rather than stdout so that it won't be redirected to file if there's any redirection done with >. It's output using \r rather than \n to ensure that reports overwrite one another, and I've added a flush so that the output doesn't hang around in buffers but is displayed straight away, even though there are no newlines (\n)s.

b) Reprogramming of ^C

  signal.signal(signal.SIGINT,sighandler)

which causes ^C to run a handler:

  def sighandler(which, frame):
  
    # This could be run at ANY point ... don't do much in here!
  
    global interim
    interim = 1
  
    # If ^C is pressed twice within a second, really do kill it!
  
    now = time.time()
    sighandler.recent += 1
    if now - sighandler.recent < 1:
      sys.exit(0)
    sighandler.recent = now

I've tried to do as little as possible in this handler, as the code could be called a just about any time. It tries to do little more than set a flag to indicate that an interim report is to be produced at an appropriate point. However, I have added extra code to pick up ^C twice in a second - if someone's hammering the keyboard then, sure, let the program exit.

Complete source code [here].

If you want ^C to generate an exception, see [here]. That's not a suitable trap where we want to resume execution straight away, as exceptions jump out from a piece of trapping code

A second version, using a thread to allow the FTP connection to be running while the main program is getting on with something else, is [here].

If you do need to program a socket directly, yes, you can do so. I've revised / refreshed myself into that - [here] is a demonstration from first principles of picking up a header from a web server. Lots of extra checking to do really, but the examples show the principles and you can build from there.

Question from Dick: What did you have for lunch yesterday?
Answer: A Sandwich, a piece of cake and some fruit.

Question from Harry: What did you have for lunch yesterday?
Answer: A Sandwich, a piece of cake and some fruit.

The answer's the same each time, no matter who asks, and it will remain the same for 24 hours no matter how many times is asked. And if working out the answer is quite a bit of work / involves getting someone else to remind you, then wouldn't it be better so remember the result and just replay it? That's the principle of caching an answer.

On yesterday's course, we were collecting a JSON object from a remote server, and doing so time and time again. That was inefficient use of the remote server, relatively slow, and an excellent demonstration case for caching the data returned which was originally called up for Tom, but is equally valid for Dick, Harry, Fiona, Betty, Susan and Bob. As a "control" case, the JSON loader example is [here] and I wrote about it [here].

Principle of basic cacheing:
• ask if we already have the data locally
• if YES, supply the local copy
• if NO, read from the remote source and store a copy locally

I've added code (in Python) that caches our JSON object into a local file - [here] - into the control example. There were a few bells and whistles required:

a) We had to see if the cached file actually existed (we checked how old it was) before we read it:

  try:
    cachetime = os.path.getmtime("cachedrecord.txt")
  except:
    cachetime = 0

b) We had to check to see if we had data that was out of date (in the example, data may live for just 20 seconds)

  if time.time() - cachetime > 20:

c) We had to handle the case of being unable to open the file to store the cached data:

  try:
    fho = open("cachedrecord.txt","w")
    fho.write(stuff)
    fho.close()
  except:
    pass

But there are two things that could be improved in that code:
• We're only caching a single specific value and
• We've added the caching code within our main program class; it's a useful utility and should be its own class for reuse and support purposes!
So during the Intermediate Python Course we improved on it!

The refactored application is [here] ... and the cache code has been reduced to:

  import kvcache
  
  localstore = kvcache.kvcache("http://www.wellho.net/services/*.json")
  stuff = localstore.get("pix")

Yes - that's all I need in my application! Of course, all the hard work's done within the class, where I used an SQLite3 database to store and retreive multiple records based on a key - "pix" in my example, but the system can store and pull back based on any unique test string key. The source code of the kvcache class is [here].

There are just two methods on the class:
• a constructor into which I pass the base URL (with a "*" for where the key is to be substituted in), and optionally a time to live (default 20 seconds) and a database file name for the class to use (defauly /tmp/mycache)
• a get method, which returns the record requested; pass in the key that you're looking for (substitute for the "*" in the URL in the constructor) and it will do the rest ... from setting up the database table, to pulling the record back, storing it based on key, checking timestamps, deleting the old record if it's expired.
All in all, this is a "classic" demonstration of the use of a class; the complicated stuff is encapsulated in the class, and all the user has to do is make a couple of simple calls ...

We could refactor further - I could replace the storage engine in the class with memcached for example, allowing cached responses to be held in memory and shared between a number of servers. And the beauty of the OO approach is that all my applications that use the kvcache should work without alteration once my refactoring has been completed with the same API.

Open a remote URL feed that provides a JSON object:

  response = urllib2.urlopen('http://www.wellho.net/services/pix.json')

Read that object in:

  stuff = response.read()

That'll give you a dict... and you can look at the keys:

  for itemname in memory.keys():
    print itemname

... you can get at individual values:

  toby = time.gmtime(memory["timedat"])
  print "This was generated at",memory["timedat"],time.strftime("%c",toby)

  if memory["lookfor"]:
    print "Searching only for",memory["lookfor"]
  else:
    print "All available records requested"

... and you can look deeper into the structure if you like:

  for record in memory["acc"]:
    print record["when"], record["which"]

Full code [here]. More about urllib2, JSON from Pyton and lots of other subjects on our Intermediate Python Course

The bridge used to be part of a major driving route, but these days it's become just a public footpath - off the Melksham to Holt road, across fields and over the railway line (take care at the unprotected crossing and over other fields down to the the water meadows.

Beyond the river, if you take a right turn you'll walk beside the river for a while, then uphill to the little hamlet of Whaddon from where you can walk down Whaddon lane to the outskirts of Trowbridge at Hilperton. And there's a lovely circular walk along the Kennet and Avon Canal to Semington, then over fields and back to the Pack Horse Bridge. Scarcely a busy road - just one quiet lane, through beautiful countryside. If you're staying with us at Well House Manor, please ask for directions.

If you've got relatives coming to stay over the next few weeks, we've got good availability of rooms for most weekends - and Melksham is an excellent base from which to explore Wiltshire too.

Historically, we have offered payment terms in Euros, US Dollars and GB pounds. But these days international money exchange and payment is much easier than it used to be, and customers now pay direct into our UK (pounds sterling) account without recent exception. We have therefore simplified our systems and our quotations are now purely in pounds. You'll find that the pound prices are (and always were) better for you that the prices we quoted in dollars or euro, simply because we no longer need to build in margins to allow for exchange rate fluctuations.

Each of our current fleet of delegate laptops is named after a location that I've traveled to as part of our training business - and I would love to visit any or all of them again. They're Albany, Brugges, Caerphilly, Dharan, Edinburgh, Frankfurt, Guadalajara, Helsinki, Izmir and Juneau!

I want to watch the TV, so I turn on then I have to select:
• Option 1 (default is 4 - special offer media package at 9.99)
• Option 8 (default is 5 - the same special offer media package; 1 at this menu would but you a pay movie
• Option 1 (Tv Channels)
• Option 1 (BBC One)

I have my own internet access. Without it, I could pay 5 pounds for an hour, or 9 pounds for 24 hours. But I would then learn that was only accessible in the lobby. It'll cost me 10 pounds for use in the room as well.

If I had forgotten anything at home, I could have bought a dental kit for a pound, a shaving kit for a pound, a sewing kit for a pound, and five pounds for a travel adapter.

Breakfast isn't included in my room rate. It will cost me 7.95 if I believe the information I was given when I booked. Or 8.95 if I believe the information in the lift.

I don't think I've spent any extras but I could so easily have had the odd pint of beer, a bit of breakfast, used the internet around the hotel, eaten a meal in (because it's rather windy out) and ended up spending 300 pounds for my three nights.

This experience is totally OPPOSITE to our policy at Well House Manor; no extras for breakfast, internet, teas and coffees - TV's free and there's no menu of costly add-ons to navigate to get to it; granted, we're not just across the road from Elstree studios!

The train at 09:01 from Melksham Station, and arrives in Weymouth at 11:03. Return from Weymouth is at 17:30, back into Melksham at 19:46.

Passengers joining at Melksham can buy their tickets on the train. A change of trains is necessary at Westbury. Free car parking available at Melksham Station.

A big "Thank you" to First Great Western, who are making the trains as long as the platforms allow, and supporting the Melksham Railway Development Group and the TransWilts Community Rail Partnership in publicising this opportunity. A representatives of both groups will be on the train.

Trains leave Melksham on Monday to Friday at 06:38 and 19:11 for Westbury, and 07:20 and 19:48 for Swindon. Saturday trains are at 09:20 and 15:21 to Swindon, and at 15:48 and 21:34 to Westbury. And on Sundays, trains leave at 17:25 and 19:53 for Swindon, and at 18:45 for Westbury. Services vary on Bank Holidays.

The TransWilts Community Rail Partnership encourages the use of the existing services by working together with the community, the rail industry and local businesses and government, and it works to promote an improvement in the service to a level appropriate for the journey requirements along the route. Such improvements will see Melksham served by a train every hour - alternately to Westbury and Swindon, giving hourly connections onwards to Bath, Bristol, and London.

The Melksham Railway Development Group promotes the use, marketing and improvement of facilities at services at Melksham in Wiltshire - a town of some 25,000 inhabitants, currently with very limited rail services and facilities.