[sf-lug] [PYCLASS] Session 3: Monday Oct 6
jim at well.com
Sat Oct 4 18:27:27 PDT 2008
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
shows the table of contents for the reference
docs for the python language.
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.
> 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
More information about the sf-lug