EXTREME NOOBIE

[skeetor]

I think "rough" is adequate, as it also describes my skill level, hehe.  The
"factory" analogy was very helpful, in the placement of my perspective (if
nothing else), when considering the "def" command.  It is called a command
isnt it?  no matter.  Thanks.


"Mike Fletcher" <mfletch at tpresence.com> wrote in message
news:CC59868A0A76D311B1F50090277B321C1F350D at VRTMAIL...
> This is rather rough, but might give you somewhere to start...
>
> A function is a "factory", the factory takes some number (sometimes zero)
of
> inputs (raw material), performs some number of operations on the inputs,
and
> either returns a result (a finished product), or raises an exception
(blows
> up).  We make these factories so that we can more readily understand how
our
> end product (what we want our program to do) will be created.  That is, we
> create an abstraction by saying "this function (factory) has the job of
> doing <<this>>, and preferably only <<this>>", that is its role, or, if
you
> like, it's "contract" with the rest of our programming world.
>
> Once we have the factory built, we don't need to worry about the machinery
> inside anymore, as we can look at the "contract" of the factory, and see
how
> the factory fits into our larger goals (instead of always having to decide
> which spout on which machine needs to be connected to which conveyor belt
on
> which other machine).
>
> A factory can have a number of inputs.  That is, it can require different
> types of "materials" to accomplish its job.  For instance, if our
factory's
> job is to create cars, it requires some wheels, some steel, some seats,
some
> glass etc.  Depending on how much of each material is received, different
> processing might occur within the factory (if we receive only three
wheels,
> we create a funky three wheeled car or blow up). In programming, we
> differentiate these "materials" (which we call "parameters") by giving
them
> names.  A typical definition of a set of inputs to a function might look
> like this:
>
> def factory( steel, glass, tires ):
> # the machinery of the function goes here
>
> In this function definition, we have defined three parameters to the
> function named "factory".  These parameters are each accessible within the
> "walls" of the function as "variables" (effectively bins in which material
> is stored).  To use the function (produce the desired output from the
> input), we pass the materials to the function like so:
>
> factory( 3000, 50, 4 )
>
> The order of the parameters determines which parameter is matched to which
> value [aside: there are other ways to match up parameters and the input
> values, but you will learn those later]. Therefore values available within
> the function are steel = 3000, glass = 50, tires = 4.  The function
performs
> its black box operation on the inputs, deciding what processing needs to
be
> done given the types of materials passed, and produces some result (or
blows
> up).  To see what this looks like in code:
>
> def factory( steel, glass, tires ):
> # processing in here
> return myAutomobile
>
> In Python, code uses the "return" statement to return a particular value
to
> the outside world.  [Geek Note: every function in Python either returns a
> value or blows up.  If no value is explicitly returned (i.e. you don't use
> the "return something" statement), the None object is returned from your
> function.]  Within the "body" of the function, you use normal code to
> manipulate the values available to you, including the inputs (parameters)
to
> the function, and those features which are part of the environment (called
> global variables or "globals") around the function.
>
> The best explanation of global variables I can think of would be the
analogy
> of a nearby stream.  The factory can decide to use the water from the
> stream, or dump pollution into the stream, and can thereby make the
> processing of inputs faster, more efficient, cheaper etc. The trade-off is
> that other users of those global resources are affected by the changes to
> the resources (which means you again have to think about the internal
> workings of the factory when you're considering your overall plan for your
> system). In some cases, the changes are beneficial, but care must be taken
> when using them.
>
> Hope this helps,
> Mike
>
>
> -----Original Message-----
> From: skeetor [mailto:skeetornospam at bellsouth.net]
> Sent: Tuesday, August 29, 2000 1:51 AM
> To: python-list at python.org
> Subject: EXTREME NOOBIE
>
>
> Whats this i hear about a function?  I just downloaded  this Python thing,
> and i am going through the online tutorials when I get to the "defining of
a
> function..."  The tutorial is real basic until that part (thats where it
> starts assuming you know how to program, Doh!)
>
> Just wondering  if some kind person can clearly and adequately explain
this
> defining of a function thing...
>
>
> --
> http://www.python.org/mailman/listinfo/python-list
>