[sf-lug] [PYCLASS] Session 3: Monday Oct 6

[jim]

   we haven't and i believe we won't: it's one 
of the combinations of ideas that will be 
assumed, like many other ideas that are assumed 
by teachers, writers, experts.... 

   "operator precedence" is a term commonly used, 
and probably the python.org web site (probably 
the language reference) has some info that shows 
relative precedence of operators. 
   trouble is the python list of operators is 
fairly small; there are other thing-a-ma-bobs 
that are not operators but are resolved along 
with operator (i.e. expression) resolution. 
   you could try thinking of () when it follows 
an identifier such as in the case of doit() as 
the "function call operator" different from () 
when it surrounds operators and operands as in '
(5 * (1 + 2 + 3) + 5) / 7 and which is the 
"grouping operator": same () characters but in 
a different context, itself a useful tho't to 
ponder. 

http://docs.python.org/reference 
shows the table of contents for the reference 
docs for the python language. 

http://docs.python.org/reference/lexical_analysis.html#id9
shows a class of operators a distinct from a 
class of delimiters. 



On Sat, 2008-10-04 at 16:36 -0700, Jeffrey Malone wrote: 
> What I believe he's asking is if we've covered it yet.  The answer is
> that we haven't.
> 
> How this works is part of the order of operations.
> 
> The order of operations of a language dictate what how expressions are
> evaluated.  Chapter 2 talks a little bit about this, but doesn't give
> the full list.
> In fact, a quick glance at the book and on Google fail to yield a straight list.
> 
> Anyway, functions are on the list, and very near the top (meaning,
> they're evaluated before most other parts -- including arithmetic).
> 
> So, as Jim stated, the functions are being called/evaluated to their
> return values.
> Noting of course that a function without a return value will produce
> results you likely don't want.
> 
> Jeffrey.
> 
> On Sat, Oct 4, 2008 at 3:21 PM, jim <jim at well.com> wrote:
> >
> >   i don't think it ever will be.
> >   each function call resolves to the value
> > it returns (my sloppy example did not include
> > an explicit return statement in the function
> > body, i can't remember if the chapters
> > included that info).
> >   assuming "la la la" includes a return
> > statement, do_twice(6,3) would return 216,
> > do_twice(6,2) would return 36, do_once(6)
> > would return 6, all while the interpreter
> > was still working on the statement: the
> > values would remain while the addition
> > operation was resolved, then the sum would
> > be assigned to answer.
> >
> >
> > On Sat, 2008-10-04 at 14:49 -0700, Alex Kleider wrote:
> >>
> >> a_kleider at yahoo.com
> >>
> >>
> >> --- On Sat, 10/4/08, jim <jim at well.com> wrote:
> >>
> >> > not necessarily. write the functions
> >> > (at top) then call them as you need them
> >> > for each specific arithmetic requirement.
> >> >    how elegantly to combine the results
> >> > of multiple calls for a single arithmetic
> >> > result seems elusive: i don't like the
> >> > summing idea, though i can't say why
> >> > (probably gut feel desire for a single
> >> > does_all() function call).
> >> >
> >> > def do_twice(value, recdepth):
> >> >     # la la la
> >>
> >>
> >> Has the following syntax ( "adding" function calls) been introduced yet?
> >>
> >>
> >> >
> >> > answer = do_twice(6,3) + do_twice(6,2) + do_once(6)
> >> >
> >> >
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> sf-lug mailing list
> >> sf-lug at linuxmafia.com
> >> http://linuxmafia.com/mailman/listinfo/sf-lug
> >>
> >
> >
> > _______________________________________________
> > sf-lug mailing list
> > sf-lug at linuxmafia.com
> > http://linuxmafia.com/mailman/listinfo/sf-lug
> >
> 
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
>