Thoughts on Guido's ITC audio interview

[Dave Benjamin]

Guido gave a good, long interview, available at IT Conversations, as was
recently announced by Dr. Dobb's Python-URL! The audio clips are available
here:

http://www.itconversations.com/shows/detail545.html
http://www.itconversations.com/shows/detail559.html

I'd like to comment on a few parts of that interview.

One thing Guido mentions in his comparison of ABC (Python's predecessor) and
Python is how ABC was inextricably tied to its environment (a la Smalltalk),
where Python, though it supports an interactive mode, follows more of a
UNIX-style "do one thing well" philosophy, and was designed to integrate
with other tools rather than being a whole world to its own.

I find that a similar comparison can be made between Python and Java. Java's
startup time is so long that it is not practical for writing small tools for
use in command-line scripts, and the propensity toward application servers
and integrated development environments suggests a strong preference for a
monolithic, self-contained, single-language environments. On the other hand,
even though internally "there's only one way to do it" in Python, Python
itself is one of many ways to develop software, and does not insist on being
the one perfect way to do it. You can use whatever editor you like, and the
language doesn't go out of its way to make it difficult to use other
programs and processes, including the operating system if so desired.

It is a bit ironic that, according to Guido, the command-line interpreter
interface to Python was more of an afterthought, since my whole experience
with Python has very much centered around the interpreter. Like many, I
think, my first use for Python was as a calculator. =) In fact, since
discovering Python, I've been very resistant toward learning any language
that doesn't have an interpreter. Ruby, Scheme, OCaml and SML/NJ have been
fun to learn because I can tinker with them at the command line. "perl -de
42" is rather frustrating to use, as is Haskell's "hugs" due to the
inability to define new functions at the command line.

Command-line interfaces are a great way to get up to speed on new languages
and libraries. One of the advantages of Python is that it allows you to
graft a CLI onto environments that weren't designed with one. For instance,
Jython gives Java a command-line interface, and this makes working with Java
much more tolerable since you can interact with libraries in real-time and
learn how they behave at runtime. Likewise with PythonWin and COM scripting.
I am glad to see that IronPython is designed with a command-line interpreter
as well, should I ever need to learn my way around .NET in a hurry.

Guido makes a funny jab at Paul Graham about Graham's nine things that make
Lisp Lisp (available here: http://www.paulgraham.com/icad.html) - I had read
this essay many times but never saw the subtle irony behind claims of
"Greenspunning" : in order to claim that a language is approaching Lisp, you
have to define what it is about Lisp that other languages are purportedly
emulating, and this begs the question of why you have the authority to
declare which 9 (or n) attributes of Lisp are most important. I like Paul
Graham and his essays a lot, but I must admit I had to laugh too when I
heard the way Guido framed this argument. I'm not so sure that Python has 8
out of 9, though: the statement/expression dichotomy rules out #6, and the
lack of macros rules out #9. These are arguable, depending on how you define
things, but I think the most obvious thing that Python lacks compared with
Lisp and Scheme (and also Ruby) is a symbol type (#7). I'm in the process of
trying to understand what symbols are good for, outside the context of Lisp
and its nested lists of symbols as executable code. Ruby seems to have come
up with some creative uses for symbols within Python-like syntax, though I
haven't seen anything terribly compelling so far.

Guido briefly summarizes language comparisons with other languages:

- Perl: similar niche, but Perl is for regexes and text processing, and
Python is for objects, data structures, and more general-purpose
programming. Obligatory TMTOWTDI argument.
- PHP: very successful at its niche, being a point-solution for adding
bits of script to web pages. Not very useful outside that context, and
lots of language-design gaffes.
- Java: the usual static vs. dynamic, static analysis vs. unit testing
arguments. Guido says that there's such a small amount of problems that
can be caught at compile time, and even the smallest amount of unit
testing would also catch these problems. "The blindness of that [static]
position... escapes me."
- C/C++: same arguments as Java, plus most programmers aren't up to the
task of manual memory-management.
- Lisp: even though there's no code-equals-data in Python, you still have
the compiler available at runtime, and there's a lot you can do to treat
code as data even though they're not syntactically idnentical.
- Smalltalk: very similar to Python, but Python is easier to integrate
into existing shops that use other languages, mainly (IMO) because
Smalltalk is a self-contained, integrated environment so the cost of
introducing it is much higher

There was also some discussion on why Java seems to be such a memory hog.
Guido chalks it up to Java's "fancy schmancy garbage collection technology"
with its heaps and threads and insistance on far-reaching low-level control
over all the poitners in the heap. It is a bit ironic that (C)Python with its
simple reference-counting plus cycle-detection seems much less
resource-hungry than Java's GC, even though most language experts consider
GC to be a vastly better technique. But I think this has more to do with
Java's particular implementaion of GC; OCaml, for instance, is
garbage-collected but has a very lean memory footprint.

I think Python's decision to use reference counting was an instance of
worse-is-better: at the time, reference counting was already known not to be
"the right thing", but it worked, and the implementation was simple.
Likewise with dynamic typing versus type inference. It seems that Guido
shares Alan Kay's viewpoint that type inference is really "the right thing",
but modern language technology is really not ready to make it mainstream,
whereas dynamic typing works today, and is arguably a better "worse"
solution than explicit/manifest static typing due to its verbosity.

From the perspective of writing C extensions, Guido claims that the amount
of pain (regarding memory management) is about the same whether you're
extending a reference-counted language like CPython or a garbage collected
language like Java. Anyone with experience writing C extensions want to
comment on this?

Type inferencing is especially difficult to add to a dynamically typed
language, and in general I think results are much better if you have type
inference from the very beginning (like ML and Haskell) rather than trying
to retrofit it later. Guido says that they've only been able to get it to
work reliably in Python with constants, which isn't very useful.

Regarding Ruby, Guido said that the community is much smaller than Python,
and that it's much more of a "better Perl" than a "better Python". I think
that, despite claims by both Guido and Matz, Ruby sits pretty much on the
fence betwee the two languages. Guido says he dislikes the code block syntax
in Ruby, but doesn't make it clear whether it's the syntax he dislikes or
the code blocks themselves. He does mention that if you like Smalltalk,
you'll probably like Ruby because of the code blocks...

Generators and iterators are, according to Guido, an "80% solution" for the
kinds of things people use code blocks for in Ruby. I think that the
newly-proposed PEP 343 offers adds another 5-10% to the solution, perhaps;
soon, Python will be able to do resource management in addition to iteration
patterns without the use of code blocks. I can still think of additional
uses for code blocks, and I have to wonder how many "point solutions" Python
is going to gain in attempt to avoid adding code blocks to the language.
This is not to say that I don't think generators or the newly proposed
"with" keyword are cool features to have.

(Upon review, I realize that Guido made the "80% solution" comment
regarding generators vs. continuations, not code blocks. Still, generators
are far more specific of a tool than either continuations or blocks.)

Someone in the audience mentioned that the CPython VM is so solid they're
surprised nobody's implemented a Java program on top of the Python VM (as
opposed to the other way around, as in Jython). Someone in the audience
surprised everyone by mentioning an actual project attempting this, called
javaclass:

http://www.boddie.org.uk/python/javaclass.html

In response to any question on how to create a language, a community, a
successful project, Guido's response tended to be the same: he doesn't
really know what he did that made it work, or made the community follow
Python so well and for so long. He says it's probably not a good idea to
start a new project by following in the footsteps of an old one. If only we
could tap a bit deeper into the mystique of successful software projects. ;)

Cheers,
Dave

[John Roth]

"Dave Benjamin" <ra***@lackingt alent.com> wrote in message
news:slrndbrse5 .71d.ra***@lack ingtalent.com.. .

Guido gave a good, long interview, available at IT Conversations, as was
recently announced by Dr. Dobb's Python-URL! The audio clips are available
[snip]
- Java: the usual static vs. dynamic, static analysis vs. unit testing
arguments. Guido says that there's such a small amount of problems that
can be caught at compile time, and even the smallest amount of unit
testing would also catch these problems. "The blindness of that
[static]
position... escapes me."
Three years ago, this was a viable arguement. Two years ago, it was
beginning to show difficulties. Today anyone who makes it can be
accused of having their head in the sand [1].

What's being ignored is that type information is useful for other things
than compile type checking. The major case in point is the way IDEs
such as IntelliJ and Eclipse use type information to do refactoring, code
completion and eventually numerous other things. A Java programmer
using IntelliJ or Eclipse can eliminate the advantage that Python
used to have, and possibly even pull ahead.

The only thing that is even vaguely similar in the Python community
is Bycycle Repair Man, and, to be brutal about it, it sucks in
comparison with what either Eclipse or IntelliJ can do.

I agree with Guido's point later in the interview that type inference
is the way to go, and that it's very difficult to retrofit it to an existing
language. Difficult does not mean impossible though. The place to
start is to go through the standard objects and make sure all return
values make sense.

I'll throw out one very simple example in the string library. The
index() and find() methods, and their variants, suffer from a bad
case of non-obviousness inherited from the C library. A very
simple replacement would fix this.

--------------------------------

findall([maxfind,] sub, [start, [end]])

findall returns a list (possibly a tuple) of the beginning index
of each substring which matches sub. If there are no matches,
an empty list is returned. At most maxfind indexes are returned.
start and end have the same meaning as in the existing find and
index methods.

--------------------------------

This version works intuitively with if statements (an empty
list is false), goes directly into for statements, can be implemented
as an iterator, and is only less efficient by a constant (creation of
the list) if the maxfind parameter is used. It never throws an
exception (unless the parameter list has the wrong types).
Its an example of a method that can be used cleanly with a
type inferencer, while the index and find methods cannot.

[snip]

John Roth

[1] I'm well aware that ostritches do not stick their heads in
the sand to avoid looking at distressing things, such as advancing
predators. It is, however, a useful metaphor.

Cheers,
Dave

[D H]

Dave Benjamin wrote:

One thing Guido mentions in his comparison of ABC (Python's predecessor) and Python is how ABC was inextricably tied to its environment (a la Smalltalk),

What surprised me was that this was the only thing he really mentioned.
He didn't mention anything about the theoretical underpinnings of ABC,
he was only involved in the implementation of ABC, and others did all
the language design. And his main criticism is a pragmatic issue with
using the ABC in real tasks like reading external files. It explains
why sometimes Python's features seem to be more implementation-driven
rather than design-driven. Such as perhaps the use of self, but a
counter-example is slicing syntax, borrowed from the language Icon
apparently.
I think when you borrow some features from a language but not all, you
have to re-evaluate every part of the language design. Colons at the
end of lines for example help readability in the ABC language because
keywords are all uppercase (unlike python). So the colons in effect
counteract some of the negative impact uppercase words place on
readability. In Python however, I don't see how colons really are
needed to help readability at all. And there are other issues too such
as changing python to be case-insensitive or making 7/4 == 1.75 instead
of 1 which even Guido wanted at one point (
http://www.linuxjournal.com/article/5028 ), but only the latter was
implemented (yet not enabled by default yet).

I find that a similar comparison can be made between Python and Java. Java's startup time is so long that it is not practical for writing small tools for use in command-line scripts, and the propensity toward application servers and integrated development environments suggests a strong preference for a monolithic, self-contained, single-language environments.
That's a very good point. Yeah you never hear of people using java for
making quick little scripts, which python and php are really great for
(among other things).

Guido makes a funny jab at Paul Graham about Graham's nine things that make
Lisp Lisp (available here: http://www.paulgraham.com/icad.html) - I had read
this essay many times but never saw the subtle irony behind claims of
"Greenspunning" : in order to claim that a language is approaching Lisp, you
have to define what it is about Lisp that other languages are purportedly
emulating, and this begs the question of why you have the authority to
declare which 9 (or n) attributes of Lisp are most important. I like Paul
Graham and his essays a lot, but I must admit I had to laugh too when I
heard the way Guido framed this argument. I'm not so sure that Python has 8
out of 9, though: the statement/expression dichotomy rules out #6, and the
lack of macros rules out #9. These are arguable, depending on how you define
things, but I think the most obvious thing that Python lacks compared with
Lisp and Scheme (and also Ruby) is a symbol type (#7). I'm in the process of
trying to understand what symbols are good for, outside the context of Lisp
and its nested lists of symbols as executable code. Ruby seems to have come
up with some creative uses for symbols within Python-like syntax, though I
haven't seen anything terribly compelling so far.
Other python extensions and descendants I mentioned in this note are
exploring the two main things lisp has but python doesn't - #6
eliminating the expression/statement distinction (at least in some cases
like assignments), and #9 macros:
http://groups-beta.google.com/group/...de=print&hl=en

- Java: the usual static vs. dynamic, static analysis vs. unit testing
arguments. Guido says that there's such a small amount of problems that
can be caught at compile time, and even the smallest amount of unit
testing would also catch these problems. "The blindness of that [static]
position... escapes me."
As pointed out elsewhere, type declarations also help with documenting
your code, as well as dramatically speeding up your program.

I think Python's decision to use reference counting was an instance of
worse-is-better: at the time, reference counting was already known not to be
"the right thing", but it worked, and the implementation was simple.
Likewise with dynamic typing versus type inference. It seems that Guido
shares Alan Kay's viewpoint that type inference is really "the right thing",
but modern language technology is really not ready to make it mainstream,
whereas dynamic typing works today, and is arguably a better "worse"
solution than explicit/manifest static typing due to its verbosity.
That's very interesting. Type inference isn't always perfect though.
There are some cases where it can't infer the type, or it infers the
wrong type that you really want. Type inference + dynamic typing is a
good combination that can speed up your code without slowing down your
coding.
Type inferencing is especially difficult to add to a dynamically typed
language, and in general I think results are much better if you have type
inference from the very beginning (like ML and Haskell) rather than trying
to retrofit it later.
It's easier to add dynamic typing to a type inferenced, statically typed
language.
Someone in the audience mentioned that the CPython VM is so solid they're
surprised nobody's implemented a Java program on top of the Python VM (as
opposed to the other way around, as in Jython).
The CPython VM is really geared specifically for the Python alone, and
Python's dynamic typing. It's no wonder other languages haven't been
built upon it unlike the java VM or the .NET/Mono CLR.

Someone in the audience surprised everyone by mentioning an actual project attempting this, called
javaclass:

Sounds like it really is converting java classes to python classes,
which are very different things. Lot of limitations mentioned such as:
"It runs on the Python runtime which does not have the security,
threading and just-in-time compiler features that people enjoy about
Java runtimes"

[Steven D'Aprano]

On Sat, 25 Jun 2005 19:31:20 -0600, John Roth wrote:

"Dave Benjamin" <ra***@lackingt alent.com> wrote in message
news:slrndbrse5 .71d.ra***@lack ingtalent.com.. .

Guido gave a good, long interview, available at IT Conversations, as was
recently announced by Dr. Dobb's Python-URL! The audio clips are available
[snip]

- Java: the usual static vs. dynamic, static analysis vs. unit testing
arguments. Guido says that there's such a small amount of problems that
can be caught at compile time, and even the smallest amount of unit
testing would also catch these problems. "The blindness of that
[static]
position... escapes me."

Three years ago, this was a viable arguement. Two years ago, it was
beginning to show difficulties. Today anyone who makes it can be
accused of having their head in the sand [1].

What's being ignored is that type information is useful for other things
than compile type checking. The major case in point is the way IDEs
such as IntelliJ and Eclipse use type information to do refactoring, code
completion and eventually numerous other things. A Java programmer
using IntelliJ or Eclipse can eliminate the advantage that Python
used to have, and possibly even pull ahead.

I haven't used IntelliJ or Eclipse, so I guess I'll have to take your word
for how wonderful they are.

[snip] I'll throw out one very simple example in the string library. The
index() and find() methods, and their variants, suffer from a bad case
of non-obviousness inherited from the C library.
It must be an very bad case of non-obviousness indeed, because it isn't
obvious to me at all what particular bit of non-obviousness it is that
you are referring to.
A very simple
replacement would fix this.

--------------------------------

findall([maxfind,] sub, [start, [end]])

findall returns a list (possibly a tuple) of the beginning index of each
substring which matches sub. If there are no matches, an empty list is
returned. At most maxfind indexes are returned. start and end have the
same meaning as in the existing find and index methods.
Am I the only one who has reservations about having to build a list of all
the matches before doing anything with them?

s = "a" * 10000000 # 10 MB of data to search
L = s.findall("a") # lots of matches means L is very large

or imagine a more complex case where I have to programmaticall y change my
search string as I go. I might not know how many matches I need until I
have found them and can analyse the text around the match.

Seems to me that rather than having to find all matches regardless of what
you actually want, it would be better to turn find into a generator. Then
findall becomes list(find) and you still have the flexibility of finding
matches one at a time.

This version works intuitively with if statements (an empty list is
false), goes directly into for statements, can be implemented as an
iterator, and is only less efficient by a constant (creation of the
list) if the maxfind parameter is used. It never throws an exception
(unless the parameter list has the wrong types). Its an example of a
method that can be used cleanly with a type inferencer, while the index
and find methods cannot.

Er, how does that last one work? How can findall be used cleanly? Why
can't find?
--
Steven.

[John Roth]

"Steven D'Aprano" <st***@REMOVETH IScyber.com.au> wrote in message
news:pa******** *************** *****@REMOVETHI Scyber.com.au.. .

On Sat, 25 Jun 2005 19:31:20 -0600, John Roth wrote:

"Dave Benjamin" <ra***@lackingt alent.com> wrote in message
news:slrndbrse5 .71d.ra***@lack ingtalent.com.. .

Guido gave a good, long interview, available at IT Conversations, as was
recently announced by Dr. Dobb's Python-URL! The audio clips are
available
[snip]

- Java: the usual static vs. dynamic, static analysis vs. unit testing
arguments. Guido says that there's such a small amount of problems
that
can be caught at compile time, and even the smallest amount of unit
testing would also catch these problems. "The blindness of that
[static]
position... escapes me."

Three years ago, this was a viable arguement. Two years ago, it was
beginning to show difficulties. Today anyone who makes it can be
accused of having their head in the sand [1].

What's being ignored is that type information is useful for other things
than compile type checking. The major case in point is the way IDEs
such as IntelliJ and Eclipse use type information to do refactoring, code
completion and eventually numerous other things. A Java programmer
using IntelliJ or Eclipse can eliminate the advantage that Python
used to have, and possibly even pull ahead.

I haven't used IntelliJ or Eclipse, so I guess I'll have to take your word
for how wonderful they are.

You might want to look at something outside of Python. The world
changes, and if you keep your eyes closed, you might not notice
it changing until it rolls over you.
[snip]

I'll throw out one very simple example in the string library. The
index() and find() methods, and their variants, suffer from a bad case
of non-obviousness inherited from the C library.
It must be an very bad case of non-obviousness indeed, because it isn't
obvious to me at all what particular bit of non-obviousness it is that
you are referring to.

The result of find() cannot be used cleanly in an if statement; you
need to compare it to -1. This is not obvious to a novice, and is
a fertile source of mistakes. It's an irregularity that has to be checked
for.

A very simple
replacement would fix this.

--------------------------------

findall([maxfind,] sub, [start, [end]])

findall returns a list (possibly a tuple) of the beginning index of each
substring which matches sub. If there are no matches, an empty list is
returned. At most maxfind indexes are returned. start and end have the
same meaning as in the existing find and index methods.
Am I the only one who has reservations about having to build a list of all
the matches before doing anything with them?

You don't have to build a list of all the matches. First, that's what the
maxfind parameter is all about, second, as I said below, it could be
implemented as an iterator. I'd expect that to happen if it was going
to be used in a for statement.

s = "a" * 10000000 # 10 MB of data to search
L = s.findall("a") # lots of matches means L is very large

or imagine a more complex case where I have to programmaticall y change my
search string as I go. I might not know how many matches I need until I
have found them and can analyse the text around the match.

Seems to me that rather than having to find all matches regardless of what
you actually want, it would be better to turn find into a generator. Then
findall becomes list(find) and you still have the flexibility of finding
matches one at a time.
See below. I covered it.

This version works intuitively with if statements (an empty list is
false), goes directly into for statements, can be implemented as an
iterator, and is only less efficient by a constant (creation of the
list) if the maxfind parameter is used. It never throws an exception
(unless the parameter list has the wrong types). Its an example of a
method that can be used cleanly with a type inferencer, while the index
and find methods cannot.

Er, how does that last one work? How can findall be used cleanly? Why
can't find?

findall() has a definite type: a list of integers, specifically a list of
integers
that are legitimate indexes into a specific string. The result of find()
does
not have this property: it can be an integer that is an index into the
string,
or it can be a -1. Index can either return an index into the string, or it
can throw an exception. Both of these are complex result types that
hinder further type inference.

John Roth


--
Steven.

[Steven D'Aprano]

On Sat, 25 Jun 2005 23:49:40 -0600, John Roth wrote:

What's being ignored is that type information is useful for other
things than compile type checking. The major case in point is the way
IDEs such as IntelliJ and Eclipse use type information to do
refactoring, code completion and eventually numerous other things. A
Java programmer using IntelliJ or Eclipse can eliminate the advantage
that Python used to have, and possibly even pull ahead.
I haven't used IntelliJ or Eclipse, so I guess I'll have to take your
word for how wonderful they are.

You might want to look at something outside of Python. The world
changes, and if you keep your eyes closed, you might not notice it
changing until it rolls over you.

If and when I have personal experience with either of these IDEs, I'll
be sure to let you know if I disagree with you. But until then, since I
have no reason to doubt what you say, and life is too short to check
everything in the world, I will accept your opinion on IntelliJ and
Eclipse.

[snip]

I'll throw out one very simple example in the string library. The
index() and find() methods, and their variants, suffer from a bad case
of non-obviousness inherited from the C library.

It must be an very bad case of non-obviousness indeed, because it isn't
obvious to me at all what particular bit of non-obviousness it is that
you are referring to.

The result of find() cannot be used cleanly in an if statement; you need
to compare it to -1. This is not obvious to a novice, and is a fertile
source of mistakes. It's an irregularity that has to be checked for.

Oh, that? It was obvious to me from the moment I understood that strings
were indexed from 0, not 1. How else could it work?

find() doesn't return a truth-value, it returns an index. You can't
sensibly use that index where Python expects a truth-value, but then you
also can't use it where Python expects a dict or a tuple or a function. I
realised that in about 5 seconds, was disappointed that Python used
0-based indexing rather than 1-based, and got over it. I never once even
tried passing the index returned by find() to if.

Yes, a lot of novices make that mistake. Shame on them. I've made plenty
of stupid mistakes in my time, and no doubt I will continue to do so. When
I make a stupid mistake, I am ashamed at MY stupid mistake, and don't
blame the language for my failures.

(I have writen p = S.find(substr); if p >= -1: in error.)

[snip]

Am I the only one who has reservations about having to build a list of
all the matches before doing anything with them?

You don't have to build a list of all the matches. First, that's what
the maxfind parameter is all about, second, as I said below, it could be
implemented as an iterator. I'd expect that to happen if it was going to
be used in a for statement.

Firstly, I've already noted that sometimes you can't predict before hand
how many matches you need, so maxfind doesn't always help.

And as for it being an iterator, I quote your specification for what
findall should do:

"findall returns a list (possibly a tuple) of the beginning index of each
substring which matches sub. If there are no matches, an empty list is
returned."

Whether it is implemented as an iterator or not is irrelevant: it still
has to package up all those yields and stick them in a list before
returning that list.

I believe there is a case for turning find() into an iterator. There might
even be a good case to make for a function findall. But I think it is a
terrible idea to replace find() with a function which "returns a list of
the beginning index of each substring which matches".

You are welcome to change the specifications of findall() and turn it into
an iterator which returns each match one at a time instead of all at once,
but then the name is misleading, wouldn't you agree?

This version works intuitively with if statements (an empty list is
false), goes directly into for statements, can be implemented as an
iterator, and is only less efficient by a constant (creation of the
list) if the maxfind parameter is used. It never throws an exception
(unless the parameter list has the wrong types). Its an example of a
method that can be used cleanly with a type inferencer, while the
index and find methods cannot.

Er, how does that last one work? How can findall be used cleanly? Why
can't find?

findall() has a definite type: a list of integers, specifically a list
of integers
that are legitimate indexes into a specific string.

Not according to your specification. It can also return an empty list.
There are no legitimate indexes in an empty list. If your IDE or compiler
or other tool can deal with that special case, why can't it deal with the
special case of find returning -1?

In any case, there is no such type as "legitimate indexes", and there
can't be for arbitrary strings. In general, you don't know the length of
either the substring or the main string until runtime. Since you don't
know both lengths, you can't tell which ints are legitimate indexes and
which are not.

For arbitrary strings, length unknown until runtime, the best you can do
is allow any index > -1. And if you are going to do that, then it is not
really such a big deal to allow any index >= -1 instead.

Yes, an index of -1 has a different meaning than 0 or 1 or 2, but in the
findall case, a return result of [] has a different meaning than a return
result of [0, 1, 2]. You are just exchanging one special case for another
special case.

The result of find() does
not have this property: it can be an integer that is an index into the
string,
or it can be a -1.
Both of which are ints. What you are talking about isn't really TYPE
checking, but more like VALUE checking.
Index can either return an index into the string, or
it can throw an exception. Both of these are complex result types that
hinder further type inference.

Why? index doesn't return an exception, it raises it. The return value
is always a non-negative int. Any function can in principle raise an
exception. If "can raise an exception" is enough to confuse the
type-checking tools, then you have some serious trouble.

--
Steven.

[George Sakkis]

"Steven D'Aprano" <st***@REMOVETH IScyber.com.au> wrote:

You are welcome to change the specifications of findall() and turn it into
an iterator which returns each match one at a time instead of all at once,
but then the name is misleading, wouldn't you agree?

The regex module has since 2.2 a function (and method for regex
objects) called finditer that does exactly that. Perhaps str (and
unicode) should have it too for consistency ?

George

[Scott David Daniels]

Dave Benjamin wrote:

...
I think Python's decision to use reference counting was an instance of
worse-is-better: at the time, reference counting was already known not to be
"the right thing", but it worked, and the implementation was simple.
Likewise with dynamic typing versus type inference. It seems that Guido
shares Alan Kay's viewpoint that type inference is really "the right thing",
but modern language technology is really not ready to make it mainstream,
whereas dynamic typing works today, and is arguably a better "worse"
solution than explicit/manifest static typing due to its verbosity.

From the perspective of writing C extensions, Guido claims that the amount
of pain (regarding memory management) is about the same whether you're
extending a reference-counted language like CPython or a garbage collected
language like Java. Anyone with experience writing C extensions want to
comment on this? This is probably true for extensions written from scratch. From the
point of view of connecting an existing block of code, Python made a
great choice. If allocated memory doesn't need to move, and the garbage
collector needn't get to _all_ the references in the system, the
extension can make blocks of memory and include references to it in
their own code, in their own format. They simply need to hold the
objects in a Python-visible way. If the memory system needs to move
allocated blocks, many data structures lose their efficiency in a
haze of either adjusting and identifying references or indirection
through piles of tables. One of the hard problems of talking "cross-
language" has to do with "who is in charge of memory."

Lots of languages are happy to allow interaction with another language
as long as the other language is restricted to writing subroutines
fitting the model of "the language really in charge." The fights are
usually about memory allocation, non-standard flow of control, and
intermediate data structures. C is easy to talk to because it was
conceived as a "portable assembly language". Only straight assembler
is easier to write language extensions in, because only assembly has
less of a preconception of how memory is used and what code is and is
not allowed to do. If you want to know pure hell, try to write a
program that has significant code in both Smalltalk and Lisp (or even
better, ML) in the same address space. They both want to be in charge,
and you will quickly decide the best thing to do is put each language
into its own process.
Type inferencing is especially difficult to add to a dynamically typed
language, and in general I think results are much better if you have type
inference from the very beginning (like ML and Haskell) rather than trying
to retrofit it later. Guido says that they've only been able to get it to
work reliably in Python with constants, which isn't very useful.

Look at the Self language. That language has less of a surface concept
of type than Python (classes are not defined). Still, Self was/is used
as a platform to investigate type inferencing, code specialization, and
native code generation.
--Scott David Daniels
Sc***********@A cm.Org

[Sakesun Roykiattisak]

What's being ignored is that type information is useful for other things
than compile type checking. The major case in point is the way IDEs
such as IntelliJ and Eclipse use type information to do refactoring, code
completion and eventually numerous other things. A Java programmer
using IntelliJ or Eclipse can eliminate the advantage that Python
used to have, and possibly even pull ahead.

1. Automatic refactoring never solve the readability issue.
2. I've never been lucky enough to have enough resource for those IDE.
3. Python solve my problem.

[Aahz]

In article <11************ *@news.supernew s.com>,
John Roth <ne********@jhr othjr.com> wrote:

What's being ignored is that type information is useful for other
things than compile type checking. The major case in point is the
way IDEs such as IntelliJ and Eclipse use type information to do
refactoring, code completion and eventually numerous other things. A
Java programmer using IntelliJ or Eclipse can eliminate the advantage
that Python used to have, and possibly even pull ahead.

Perhaps. But adding the time to learn those IDEs in addition to the time
to learn Java is ridiculous. I've been forced to use Java a bit to
support credit cards for our web application; I've got a friend whose
Java-vs-Python argument hinges on the use of Eclipse; I was unable to
make use of Eclipse in the time I had available for the project.

Meanwhile, I'm busy with a code base that I doubt any IDE could handle...
--
Aahz (aa**@pythoncra ft.com) <*> http://www.pythoncraft.com/

f u cn rd ths, u cn gt a gd jb n nx prgrmmng.