A
Alf P. Steinbach
Is this guaranteed to work in Python 3.x?
Cheers,
- Alf
Cheers,
- Alf
Are routine objects guaranteed mutable & with dictionary?
M
Marco Mariani
Alf P. Steinbach wrote:
I don't see why it shouldn't work.
BTW, it's a function, not a "routine"
I don't see why it shouldn't work.
BTW, it's a function, not a "routine"
A
Alf P. Steinbach
* Marco Mariani:
For example,
(42).blah = 666
The question is what guarantees or absence thereof the language specification,
PEPs, intentions, whatever gives/has.
Wikipedia is your friend, <url: http://en.wikipedia.org/wiki/Subroutine>.
Cheers & hth.,
- Alf
For example,
(42).blah = 666
The question is what guarantees or absence thereof the language specification,
PEPs, intentions, whatever gives/has.
Wikipedia is your friend, <url: http://en.wikipedia.org/wiki/Subroutine>.
Cheers & hth.,
- Alf
R
Rami Chowdhury
BTW, it's a function, not a "routine"
I don't think it was a problem of comprehension, more one of
appropriate terminology -- AFAIK in Python, they're called functions,
so calling them 'routines' is likely to confuse anyone in a discussion
of Python features.
I don't think it was a problem of comprehension, more one of
appropriate terminology -- AFAIK in Python, they're called functions,
so calling them 'routines' is likely to confuse anyone in a discussion
of Python features.
L
Lie Ryan
Human language is not context-free, we can't parse human language with
LL parser.
T
Terry Reedy
Alf said:
The two docs backed up by PEPs. I suppose the docs could be clearer.
5.3.1 says "The primary must evaluate to an object of a type that
supports attribute references, which most objects do." This is true for
attribute access, but not for attribute setting. See
http://bugs.python.org/issue7436
for my suggest addition.
which says "the C and C++ programming languages, subprograms are
referred to as "functions" (or "methods" when associated with a class)."
The same is true for Python and many other languages. Some languages
have separate statements for defining functions and (non-function)
subroutines. If you want to be understood, use function. I thought you
mean 'routine' as opposed to 'special'.
Terry Jan Reedy
R
Raymond Hettinger
Yes, function attributes are guaranteed to be writable:
http://www.python.org/dev/peps/pep-0232/
Raymond
A
Alf P. Steinbach
* Raymond Hettinger:
Thanks to all, especially you and Terry.
To quote a suspected bot once rampaging the Microsoft groups, "my question has
been answered!"
Thread morphing:
Regarding my terminology, "routine" instead "function" that everybody except you
remarked on, it is of course intentional. After all, my main language is C++.
And nobody (well, very few) would accuse me of not knowing my C++.
I use the term "routine" because I think the terminology influences what we can
easily think of and what we therefore tend to use and/or discuss. In that
respect I think people need to be educated to use more language independent, or
Eiffel-like, or just historically original, terminology, because
* "function" is misleading in itself (due to the hijacking of this term in
mathematics), and
* it gets worse when you can't reasonably talk about "co-functions" or
"function-like functions".
The devolution of terminology has been so severe that now even the Wikipedia
article on this subject confounds the general concept of "routine" with the far
more specialized term "sub-routine", which is just one kind of routine. It is of
course OK with me that there is a default meaning, and that there are several
different context dependendent meanings. I'm just mentioning this as an example
that the terminology effectively constrains one's thinking, to the degree that
even a moderately long encyclopedia article on the subject fails to mention or
focus on the important aspects. Perhaps modern programmers should be forced to
study Donald Knuth's TAOCP. Or something.
Cheers,
- Alf
Thanks to all, especially you and Terry.
To quote a suspected bot once rampaging the Microsoft groups, "my question has
been answered!"
Thread morphing:
Regarding my terminology, "routine" instead "function" that everybody except you
remarked on, it is of course intentional. After all, my main language is C++.
And nobody (well, very few) would accuse me of not knowing my C++.
I use the term "routine" because I think the terminology influences what we can
easily think of and what we therefore tend to use and/or discuss. In that
respect I think people need to be educated to use more language independent, or
Eiffel-like, or just historically original, terminology, because
* "function" is misleading in itself (due to the hijacking of this term in
mathematics), and
* it gets worse when you can't reasonably talk about "co-functions" or
"function-like functions".
The devolution of terminology has been so severe that now even the Wikipedia
article on this subject confounds the general concept of "routine" with the far
more specialized term "sub-routine", which is just one kind of routine. It is of
course OK with me that there is a default meaning, and that there are several
different context dependendent meanings. I'm just mentioning this as an example
that the terminology effectively constrains one's thinking, to the degree that
even a moderately long encyclopedia article on the subject fails to mention or
focus on the important aspects. Perhaps modern programmers should be forced to
study Donald Knuth's TAOCP. Or something.
Cheers,
- Alf
A
Andreas Waldenburger
Can you please elaborate? To me, a function is something that
transforms some input to some output [1]. Which is exactly what Python
functions do, without fail.
[1] I was going to write "maps" instead of "transforms" but that seemed
odd to me (in the context of Python). So I think I sort of see where
you're going with this. But I'm still curious about the details.
/W
S
Steven D'Aprano
I think you failed to realise that your use of the term was ambiguous. It
wasn't clear that you were using "routine" as a noun, it seemed like you
were using it as an adjective, that is, "routine objects" meaning
"ordinary, common objects one would use routinely".
Your second example was:
(42).blah = 666
(which of course fails, because ints are immutable and you cannot add
attributes to them). It isn't surprising that we failed to realise you
were talking about callable objects when exactly 50% of your examples
were not callable objects. Given the context, I think we were completely
justified in thinking that you meant routine in the sense of commonly
used.
"Function" in the mathematical sense dates back to Leibniz and Johann
Bernoulli in the late seventeenth century. I'm not sure, but I think that
may have pre-dated computers by a couple of years *wink*
http://www.gap-system.org/~history/HistTopics/Functions.html
* it gets worse when you can't reasonably talk about "co-functions"
or "function-like functions".
"Co-function" is specifically a mathematical term, from trigonometry.
Sine and cosine are co-functions, because they are related via
complementary angles: the sine of an angle is equal to the cosine of the
complementary angle.
That's the only definition Google has found:
http://www.google.co.uk/search?q=define:co-function&ie=UTF-8&oe=UTF-8
Webster's dictionary agrees this is the only definition:
http://www.merriam-webster.com/dictionary/Cofunction
So I have no idea what you think a co-function (or cofunction) is, or why
you can't talk about it.
As for "function-like functions", I can't think why you would want to use
that term! If something is a function, it's obviously function-like, in
the same way that cats are cat-like and chairs are chair-like.
If you want to talk about "function-like objects", or "function-like
data", or "things that behave like functions but aren't actually
functions", that is reasonable. We have names for such things: functor
(from C++, different from functors in Haskell), or callable, or
(verbosely, in Python) "any object with a __call__ method". But function-
like functions? That would just be a function.
I'm not sure how to reply to that, since I'm not sure what you think a
"routine" is in computing.
In my experience (which dates back to the early 80s), "routine" has never
been anything but a generic term without any specific technical meaning.
That is, one might talk about the "print routines" without caring whether
they are external programs (say, printer drivers) or internal sub-
routines (functions, procedures, co-routines, methods, or even just a
chunk of code you GOTO).
What do you consider the important aspects of routines?
Perhaps. But not every car mechanic needs to be able to re-build an
engine from scratch.
Besides, if every programmer had read Knuth, what reason would we have to
feel superior to the code-monkeys? *wink*
I've-skimmed-parts-of-Knuth-and-am-therefore-superior-to-99%-of-coders-ly
y'rs,
S
sturlamolden
A mathematical function cannot have side effects. That is what
functional languages strive for. However, without allowing side-
effects, how can you control hardware (printer, file i/o, etc.)?
A Python callable is never a computer science "routine", as it always
returns a value. If no value is explicitely returned, it will silently
return None. All Python callables are functions.
Also in C, calling a void function "routine" is dubious. Fortran and
Basic have a destinction between functions and routines, however.
A
Alf P. Steinbach
* Steven D'Aprano:
One example and one counter example. I can't think of why anyone should lump
these together as examples of the same thing.
Yes, that was my point. Wink.
Right. That was my point. Wink. Heh heh. Try substituting "routine". That
is, s/function/routine/g.
See above. ;-)
Right, that was my point.
Including that with the C/Python terminology it isn't.
See the Wikipedia article and allow for some confusion on the part of the
authors. Or, if you have TAOCP handy, look it up there. However, you may
disregard Donald Knuth's definition of "reel time", I'm not invoking him as
an authority on terminology, just a handy accessible source for the general
meaning of "routine" (disclaimer: haven't looked it up for this posting, so I
can't guarantee that you'll find it, although as I recall in volume I).
Well, my experience is perhaps a bit longer, but not much. And you're on the
right track. It's a more general term, *and* it has context dependent meanings.
One of the most important aspects is the invocation model. There are many such.
Sub-routines and co-routines are the two most common special cases, but for a
little more general way of thinking about how routines are invoked and
communicate, if you can find a copy of Patrick Henry Winston's "Artificial
Intelligence" nearby, as I recall he discussed some other options in a very
clear way (illustrated with Lisp examples).
He he.
Cheers,
- Alf
One example and one counter example. I can't think of why anyone should lump
these together as examples of the same thing.
Yes, that was my point. Wink.
Right. That was my point. Wink. Heh heh.
Try substituting "routine". That is, s/function/routine/g.
See above. ;-)
Right, that was my point.
Including that with the C/Python terminology it isn't.
See the Wikipedia article and allow for some confusion on the part of the
authors. Or, if you have TAOCP handy, look it up there. However, you may
disregard Donald Knuth's definition of "reel time"
, I'm not invoking him as an authority on terminology, just a handy accessible source for the general
meaning of "routine" (disclaimer: haven't looked it up for this posting, so I
can't guarantee that you'll find it, although as I recall in volume I).
Well, my experience is perhaps a bit longer, but not much. And you're on the
right track. It's a more general term, *and* it has context dependent meanings.
One of the most important aspects is the invocation model. There are many such.
Sub-routines and co-routines are the two most common special cases, but for a
little more general way of thinking about how routines are invoked and
communicate, if you can find a copy of Patrick Henry Winston's "Artificial
Intelligence" nearby, as I recall he discussed some other options in a very
clear way (illustrated with Lisp examples).
He he.
Cheers,
- Alf
D
Dennis Lee Bieber
Well, if this were a FORTRAN IV text from the mid-70s you'd be
talking about
function subprograms
and
subroutine subprograms
A
Alf P. Steinbach
* Dennis Lee Bieber:
It's in that direction yes, but the distinction that you mention, which is
essentially the same as Pascal 'function' versus 'procedure', or Visual Basic
'function' versus 'sub', is just a distinction of two variants of subroutines.
Up above there is the more general concept of a routine, where there are more
possibilites than just subroutines; Python generators are one example.
As I mentioned earlier, in Eiffel, which is a more modern language than Fortran,
routines are still called routines. And specialized terms include "routine". So
it's not like that language independent terminology has been phased out in
general; it's mostly only in the C syntax family (e.g. Python operators come
mostly from C) that "function" is, misleadingly and with associated severe
constraints, used as a general term.
Cheers,
- Alf
It's in that direction yes, but the distinction that you mention, which is
essentially the same as Pascal 'function' versus 'procedure', or Visual Basic
'function' versus 'sub', is just a distinction of two variants of subroutines.
Up above there is the more general concept of a routine, where there are more
possibilites than just subroutines; Python generators are one example.
As I mentioned earlier, in Eiffel, which is a more modern language than Fortran,
routines are still called routines. And specialized terms include "routine". So
it's not like that language independent terminology has been phased out in
general; it's mostly only in the C syntax family (e.g. Python operators come
mostly from C) that "function" is, misleadingly and with associated severe
constraints, used as a general term.
Cheers,
- Alf
M
MRAB
In C there were originally only functions; if you didn't specify aAlf said:
return type then it would default to 'int' ('void' was a later
addition).
In Python there are only functions; if you don't explicitly return a
value then None is returned.
The distinction between functions and procedures can be helpful in
deciding whether something is Pythonic (for example, in the use of list
comprehensions), but in reality they are all still functions.
A
Alf P. Steinbach
* MRAB:
I'm sorry, but, first, looking at ways to emulate a syntax, thinking about
whether something looks like mathematical functions, the eye-candy, is pretty
irrelevant, at least IMO. To see that it is irrelevant you might consider how
that works in assembly language. Or you might consider that a call of a C++
'void' routine can be used in C++ expressions. I think that even by your mainly
visual syntax criterion that must be difficult to think of as a "function".
Another way of looking at it is that the information conveyed by a result
restricted to N=1 possible significant values, such as Python None or C
arbitrary value (all possible return values of a non-result-producing routine to
be treated as the same), is log(N)/log(2) = log(1)/whatever = 0, i.e., the
routine then produces zero information via its expression result.
Second, what's discussed isn't the distinction between various kinds of
subroutines, so that wrt. to the earlier thread it's at best a detail.
Although I think that the distinction that you and Dennis raise *is* a useful
discussion!
Cheers & hth.,
- Alf
I'm sorry, but, first, looking at ways to emulate a syntax, thinking about
whether something looks like mathematical functions, the eye-candy, is pretty
irrelevant, at least IMO. To see that it is irrelevant you might consider how
that works in assembly language. Or you might consider that a call of a C++
'void' routine can be used in C++ expressions. I think that even by your mainly
visual syntax criterion that must be difficult to think of as a "function".
Another way of looking at it is that the information conveyed by a result
restricted to N=1 possible significant values, such as Python None or C
arbitrary value (all possible return values of a non-result-producing routine to
be treated as the same), is log(N)/log(2) = log(1)/whatever = 0, i.e., the
routine then produces zero information via its expression result.
Second, what's discussed isn't the distinction between various kinds of
subroutines, so that wrt. to the earlier thread it's at best a detail.
Although I think that the distinction that you and Dennis raise *is* a useful
discussion!
Cheers & hth.,
- Alf