Returning none
Michael P. Reilly
arcege at shore.net
Fri Sep 3 16:58:26 EDT 1999
Aahz Maruch <aahz at netcom.com> wrote:
: In article <5ORz3.14$JG1.2704 at news.shore.net>,
: Michael P. Reilly <arcege at shore.net> wrote:
:>
:>One powerful, often used construct is treating callables as first
:>class: does the callable return a value? That doesn't matter, the
:>interface needs to be consistant to work properly, and currently it
:>does. Do we now have new functions for apply, map, filter to handle
:>"procedures"? (Are these now procedures?) You then have to know ahead
:>of time if the callable is a function or a "procedure". You can't mix
:>at a non-predetermined point, functions and "procedures". This just
:>adds to the complexity of the language and implementations needlessly,
:>removing important functionality.
: One could just as easily make the same argument about using string
: functions on numbers -- you have to know in advance that something is a
: string. Down this path lies the Perl approach....
I don't see how.. the interface between strings and numbers are similar
("+" and "*"; more similar than with Perl, where you have a very
isoteric autoincrement) this is the polymorphism that Python was going
for and that Perl doesn't; but strings are even more similar to lists
and tuples, and have the same interface as those.
Yes, you have to know it is a string and not a number. But this one
proposal here is to have a callable that returns some new, special
value, not two different types of callables that you could run tests
on.
-Arcege
More information about the Python-list
mailing list