Typed Python?

[beliavsky]

The majority of university students fail to recognize they're in school
for an education; if they wanted job training, they should attend a
technical training institute. Here is a quote from a student in 1980:
"FORTRAN is a dead language."

Is FORTRAN dead? No.
Do I want to write more FORTRAN code? No.
Is Python the bestest language ever? No.
Do I want to write more Python code? Sure.

One should not judge a programming language based on outdated
information.

Fortran (not spelled with all caps since the 1990 standard) continues
to evolve. The 1990 standard added array functionality, modules (in
Fortran, 'use foo, only: boo' is equivalent to 'from foo import boo'
in Python) similar to that of Numeric or Numarray, the 1995 standard
added features for parallel programming such as pure and elemental
functions (similar to Python ufunc's), and the 2003 standard added OOP
with inheritance and interoperability with C.
There is a free Fortran 95 compiler for x86 Linux and Free BSD and Mac
OS X at http://www.g95.org .

 

[Ville Vainio]

Jakub> lambda x: lambda y: f(x,y,1,2)?

Jakub> but then
Jakub> (lambda x: lambda y: f(x,y,1,2))(3, 4)

Jakub> won't work.

Of course it won't. It's the difference b/w taking 1 and 2 parameters.

(lambda x: lambda y: f(x,y,1,2))(3)(4)

will work.

I guess you will see that e.g in haskell

f 1 2

does exactly this:

((f 1) 2 )

Jakub> so much for currying?

Well, no.

 

[Jacek Generowicz]

Jacek> Though using a language in which the stuff you need already
Jacek> works the way you want it, might help more.

It's throwing baby out with the bathwater. If something is amiss in a
library, you typically don't switch the whole language (at least in
industrial/corporate setting).

But if the language has many deficiencies (as the OP suggested it did,
form his POV), and another language does not have those deficiencies,
and no other show-stopping deficiencies ... but I think that you know
that this was the point, and are being deliberately obtuse.

You would need to switch languages every other day.

No, just find the best one for your project, and stick to it.

Well, I've seen worse - some people actually *implement* new
languages

.... like Python

So performance was the problem? The OP should have said so,

I was under the impression that he had, but, upon checking, I see that
he did not.

perhaps posted some benchmarks.

Well, lemme see, Bigloo compiles down to native code, and, with type
specifications, can eliminate dynamic dispatching from your inner
loops. The concept is pretty clear. Do you really think that
benchmarks would in any way help to understand the _concept_ ... or
are you just being deliberately obtuse?

Jacek> Python provides no built-in support for pattern matching,
Jacek> therefore your average happy Pythoneer will not be familiar
Jacek> with pattern matching, the point of pattern matching, the
Jacek> benefits of pattern matching, or the situations in which
Jacek> pattern matching is a big win. If

Ok, give an example where built-in pattern matching (i.e. something
not doable with a library) would be a big win.

I am not a regular user of pattern matching, so I am probably not a
good person to champion it. This in no way takes away from my point
which is this:

Fans of programming language A typically believe that features of
language B, which are absent from A, are not very useful. This is
usually NOT because the features are not useful, but because the
person in question is ignorant of their advantages. Their ignorance
is typically borne of the absence of the feature from language A.

.... but I have a feeling that you already knew that.

Jacek> ... yup, you prove my point exactly.

Last time I checked, pattern matching essentially *is* about

1. Finding the pattern that matches the valuable of a variable

2. Unpacking the found value to a tuple.

And anything you can do in Python, you can do on a Turing Machine. Why
use Python, when a roll of infinite tape and a few cog wheels "will
typically do fine"?

.... but I have a feeling you already knew that.

 

[Jacek Generowicz]

Jakub> lambda x: lambda y: f(x,y,1,2)?

Jakub> but then
Jakub> (lambda x: lambda y: f(x,y,1,2))(3, 4)

Jakub> won't work.

Of course it won't. It's the difference b/w taking 1 and 2 parameters.

Which is pretty much the point of currying.

(lambda x: lambda y: f(x,y,1,2))(3)(4)

will work.

I guess you will see that e.g in haskell

f 1 2

does exactly this:

((f 1) 2 )

Jakub> so much for currying?

Well, no.

Well, yes.

In Haskell, both

f 1

and

f 1 2

will work, while in Python you have to install the plumbing yourself
every time.

You can write object-oriented programs in C ... but you have to
intstall the plumbing yourself every time. C supports object
orientation to about the same extent that Python supports currying.

You seem to be consistently implying (I just followed up another of
your posts, which implies similar sentiments) that built-in features
of other languages offer them no advantages over Python, because you
can simulate them all in Python. Why don't you take that line of
thought to its logical conclusion and program in a Turing Machine ?

Python offers no advantages over a Turing Machine, because you can
simulate all of Python's features in a Turing Machine.

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[Ville Vainio]

[Jacek Generowicz]

Jacek> Python provides no built-in support for pattern matching,
Jacek> therefore your average happy Pythoneer will not be familiar
Jacek> with pattern matching, the point of pattern matching, the
Jacek> benefits of pattern matching, or the situations in which
Jacek> pattern matching is a big win. If

Ok, give an example where built-in pattern matching (i.e. something
not doable with a library) would be a big win.

In one of my previous Scheme works, I needed pattern matching for
strings as well as for tree structures, and ended up implementing both.

Python has string pattern matching through the `re' library. It also
has a fairly limited structure pattern matching built-in, through tuple
unpacking, like in assignments or in function argument passing. The
trick is that tuple unpacking acts recursively (something I guess many
Pythoneers do not know, or at least, do not use). Another problem
with structure matching in Python is that a failed matching raises an
exception, something slow for applications heavy on pattern matching.
For very simple applications however, Python easily does as it stands.

though - a couple of if-elif's will typically do fine (because that's
what pattern matching essentially is).

Jacek> ... yup, you prove my point exactly.

And Jacek is right, once again. One should avoid being too judgemental,
especially when not much familiar with problems at stake. (Yet, I did
exactly this a few times, in the youth of my programmer life. It took a
while before I began to see how presumptuous I might have been at times
.) I know that some people trigger their own education by challenging
others, which is not that humble to start with, likely irritating to the
challenged people, and not looking very polite to the casual observers.

Last time I checked, pattern matching essentially *is* about [...]

Hopefully, life will give you the opportunity for many more checks!
Pattern matching is by far not limited to strings, and whole areas of
technology are either dedicated or based on pattern matching.

 

[Arthur]

Why not have fun while learning computer science?

Yes please, fun.

I am somewhere between a CP4E-er and a "computer science" -er.

There is much to be done with programming, IMO, in the educuational
process that is something short of hard core computer science.
Practical programming as a tool for other learning and teaching
possiblities. But in areas that themselves tend to be tehnical and
demanding (mathematics and science, the most obvious), so the
association of these efforts with "technical" and "demanding" need not
be soft pedaled. It need not be "easy".

Scheme is just a
programming language. It is not in and of itself a revelation of the
deepest concepts of computer science. Python supports recursion, second
order functions, numerical programming and hundreds of other important
concepts. In my mind, Scheme actually lacks important stuff like the
idea that types can be created (not simulated, but CREATED) by
programmers and not just language designers. It also lacks various other
OOP concepts (in its standard form).

For the things I hoped to accomplish by learning to program - based on
available compatible libraries and tools - Java would have been a more
practical choice.

Not being in a position to talk to the issue of the "deepest concepts
of computer science", I would have no reason to reject Java for Python
(or Scheme).

But since my self directed efforts were not a required course, and not
designed as a career move, I did demand to be having some fun at it.

Which I think is more or less how I ended up at Python.

Hard to define why this is so. But the word "fun" is slung around the
Python community with abandon, and it is one word used within the
community that I have never found a basis to quibble with.

Art

 

[Jakub Fast]

Which is pretty much the point of currying.




Well, yes.

In Haskell, both

f 1

and

f 1 2

will work, while in Python you have to install the plumbing yourself
every time.

which is exactly what I meant.... With lambda x,y you can't just
curry the function. You can with lambda x: lambda y:, but then you can't
do regular application with it.

however, do take a look at
http://www.sourcekeg.co.uk/www.python.org/peps/pep-0309.html
which is getting in for 2.4 (?)

k

 

[Jacek Generowicz]

One should avoid being too judgemental, especially when not much
familiar with problems at stake. (Yet, I did exactly this a few
times, in the youth of my programmer life. It took a while before I
began to see how presumptuous I might have been at times .)

Hey, join the club!

Ville is welcome to join too

 

[Christopher T King]

Specifying the type in Bigloo will make the code run more quickly,
while asserting the type in Python will make the code run more slowly.

Using Psyco, which automatically generates statically-typed code, will
also make code run more quickly. If that's not enough, you can use Pyrex,
which is statically typed.

Python provides no built-in support for pattern matching, therefore [snip]
matching in its best light. Therefore, they are likely to conclude
that there is no use for pattern matching ...

Pattern matching is rarely needed outside of functional programming
languages. My understanding of pattern matching is that it is designed
not primarily to allow functions to operate on multiple data types
(which Python does implicitly), but rather to ease writing recursive
functions, i.e.:

def mangle_list(arg):

arg -> int head, tail:
return mangle_int(head), mangle_list(tail)

arg -> float head, tail:
return mangle_float(head), mangle_list(tail)

arg -> NULL:
return NULL

else:
raise TypeError

Naturally, something like this would be replaced with a list comprehension
in Python:

def mangle_list(arg):
return [mangle_object(i) for i in arg]

A binary tree structure better shows the advantage of pattern matching,
however:

def mangle_binary_tree(arg):

arg -> a, b:
return mangle_binary_tree(a),mangle_binary_tree(b)

arg -> int a:
return mangle_int(arg)

arg -> float a:
return mangle_float(arg)

else:
raise TypeError

Something like this would be better handled by a higher-level library
function in Python.

Anyways, my point is, Python programmers don't think they have a need for
pattern matching precisely because they don't have a need for it: pattern
matching primarily benefits recursive structures, such as those commonly
found in Scheme.

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[Christopher T King]

Anyways, my point is, Python programmers don't think they have a need
for pattern matching precisely because they don't have a need for it:
pattern matching primarily benefits recursive structures, such as
those commonly found in Scheme.

Deep down, recursive structures originate from the problem to solve, not
from the programming language used to solve the problem.

Scheme (and other languages as well) are well-suited to solve problems
involving recursive structures, but Python is very well-suited too. If
Python programmers don't think they have a need for pattern matching,
it's merely because they did not stumble yet on problems where it fits.

 

[Jacek Generowicz]

Using Psyco,

A lot of use it is on my Mac, my Sun ... etc.

which automatically generates statically-typed code,

Which in no way avoids dynamic dispatch _to_ said code.

If that's not enough, you can use Pyrex,

or Scheme, or Common Lisp ...

which is statically typed.

.... or C, or Fortan.

But why am I playing "pick nits in irrelevant details" with you ?

Python provides no built-in support for pattern matching, therefore [snip]
matching in its best light. Therefore, they are likely to conclude
that there is no use for pattern matching ...

Pattern matching is rarely needed outside of functional programming
languages.

Do you use pattern matching regularly in you progarms? If not, then
forgive me for not lending much weight to your opinion on the
matter. This is the crux of my original point.

My understanding of pattern matching is that it is designed
not primarily to allow functions to operate on multiple data types
(which Python does implicitly), but rather to ease writing recursive
functions, i.e.:

To ease writing functions. Finishing your sentence there would make it
more accurate.

Anyways, my point is, Python programmers don't think they have a need for
pattern matching precisely because they don't have a need for it: pattern
matching primarily benefits recursive structures, such as those commonly
found in Scheme.

Remind me, how often do you use pattern matching in your daily work ?

When I started using Python, there were no static methods in the
language. Whenever anyone asked about them, the answers typically went
along the lines of "There is no need for static methods in Python."
Guess what, Python now has built-in support for static methods, and
lots of people use them. If I took the time to think about it, I could
probably come up with at least five more examples of this nature.


Certain features absent from Python, are a concious design decision;
attribute access restriction, for example. Here you can state that you
don't need the feature because you think that having it is
detremental. But in the case of features which are just missing
because nobody has implemented them ... it's pretty daft to claim that
they are unnecessary in Python, unless you are an _expert_ in their
use.

 

[Christopher T King]

Python provides no built-in support for pattern matching, therefore [snip]
matching in its best light. Therefore, they are likely to conclude
that there is no use for pattern matching ...

Pattern matching is rarely needed outside of functional programming
languages.

Do you use pattern matching regularly in you progarms?

Aside from tuple unpacking, no. I've also never found the need to do
anything more complex when writing Python programs. I am familiar enough
with pattern matching, however, that I have found the need for it while
writing C programs, specifically those operating on recursive data
structures. I've also found the need for many other concepts that I've
never actually used before (i.e. continuations, partial function
application) while programming Python, but never pattern matching.

Do you regularly find a need for pattern matching in Python? Assuming your
answer is yes, could you give some examples of where pattern matching
could help?

 

[Hamilcar Barca]

Python offers no advantages over a Turing Machine, because you can
simulate all of Python's features in a Turing Machine.

Agreed, although personally I have other things to do between now and
8 July 2024.

 

[Paul Prescod]

Paul Prescod:




Every sufficiently advanced LISP application will eventually reimplement
Python.

You made me smile but you also made me think. If you need to use Scheme
in the "real world" you will use a Scheme with Python-like libraries,
maybe infix syntax, some form of object orientation etc. So who is
morphing into who?

With respect to Common Lisp I argue no contest: if you build the world's
biggest language from the start of course every other language will look
like a subset of it.

Paul Prescod

 

[Paul Prescod]

...
In Haskell, both

f 1

and

f 1 2

will work, while in Python you have to install the plumbing yourself
every time.

But what does this have to do with Scheme, which was the subject of
conversation? We were trying to decide what deep computer science
concepts you could learn from Scheme that you couldn't from Python.

One thing I find interesting about these deep computer science concepts
seem to be mostly just language features. I mean Java is in some sense a
really good computer science language because of all of the threading
stuff it has: you'll learn about concurrent programming better with Java
than with R4RS scheme!

It might be interesting if someone rewrote SICP for Python...would
Python exhibit big conceptual gaps?

Paul Prescod

 

[Paul Prescod]

...
You don't seem to have taken it this way, but I don't intend to bash
Python.

I didn't take it that way. I'm just trying to understand to what extent
your position is yours and to what extent it is just common wisdom.
Languages deemed "good for education" do not have a good history: BASIC,
Pascal, etc. Why was Pascal good for teaching? In retrospect it really
wasn't that great. But at the time it was common wisdom.

...

How about currying and deferred list evaluation?

Between generators, nested functions and generator expressions I think
we're doing okay. But why are these more important concepts than (let's
say) threads or network programming? Because the latter are tainted by
real-world usefulness?

Computer science is a really massive field and I think that for every
pattern that is made easy to learn because it falls out of the language
syntax ("deferred list evaluation: now I understand lazy processing in
general") there are ten that do not (cache coherency, context-free
grammars, relational algebra, tree transformations, algorithmic
complexity, state machines, quick sort, floating point numbers, graph
theory, text searching).

Therefore we should look for a language that is fun, easy to learn
(relatively speaking!) and highly productive but not expect the language
itself to deliver the CS education. Students will probably learn more
from the library than from the language. I'd go so far as to say that
what you are looking for is a language that gets out of your way to the
greatest extent. The language is primarily a notation...not a concept.

Paul Prescod

 

[Paul Prescod]

Paul Prescod:




Every sufficiently advanced LISP application will eventually reimplement
Python.

I hereby dub thee "Hodgson's Law".

Paul Prescod

 

[Hamilcar Barca]

I'm just trying to understand to what extent your position is yours and
to what extent it is just common wisdom.

I think common wisdom would say VisualBasic and Java, for example, should
be the primary languages; when I first started school, FORTRAN, COBOL,
APL, and (enhanced) Dartmouth BASIC seemed big.

Languages deemed "good for education" do not have a good history: BASIC,
Pascal, etc. Why was Pascal good for teaching?

Pascal was big because it had a reasonably simple syntax, strong typing,
plain block structure, among other things. Did this make it the best
choice at the time? I don't think so. Was it good enough? Yes.

If I were making the decision between say FORTRAN, COBOL, APL, Pascal,
Modula, C++, Java, C#, VBA, or Python, I'd choose Python quickly. Adding
Smalltalk and Scheme would make me think harder. Perhaps it was you who
said it (or maybe I imagined it), but the availability of a work the
quality of Abelson and Sussman for Python and Smalltalk would make the
decision quite hard.

But why are these more important concepts than (let's say) threads or
network programming?

I don't see why network programming is particularly important for teaching
basic concepts. I do think parallel programming worthy of study but it's
not quite what I mean. I neglected to say so, but my comments were
directed toward introductory education.

Because the latter are tainted by real-world usefulness?

I don't worry about a taint; the choice of language for education should
not be based on salability or popularity, but rather on its ability to
express the concepts to be demonstrated by writing programs.

Therefore we should look for a language that is fun, easy to learn
(relatively speaking!) and highly productive but not expect the language
itself to deliver the CS education.

Fun isn't fundamental be neither should pain be inflicted gratuitously.

Students will probably learn more from the library than from the
language.

Perhaps or perhaps not, but...

I'd go so far as to say that
what you are looking for is a language that gets out of your way to the
greatest extent. The language is primarily a notation...not a concept.

I'd go so far as to say that I agree completely with your point.

I'm a bit tired of the attitude of undergraduates, especially, who want to
be taught a language because they think it will get them a job.
Undergratuates as a rule don't know diddly-squat, if you'll excuse the
technical terminology. I'm seriously tired of the rah-rah,
jump-on-the-bandwagon, my-krew's-using-it rationale for language choice.

I'm glad this isn't your attitude and anyway it's a different rant.

 

[Jacek Generowicz]

Do you regularly find a need for pattern matching in Python?

No. (As I already mentioned upthread.)

Which probably says more about my ignorance and lack of imagination
(or the boring range of programs I write) than about how useful
pattern matching may or may not be in Python.

That has been my point throghout.

 

[Hamilcar Barca]

Hamilcar> Is this a good place to insert my "Smalltalk is the only
Hamilcar> language good enough for teaching people to program"
Hamilcar> rant?

What's better about Smalltalk compared to Python, educationally?

Although I meant what I said, I said it here as a joke.

Just a brief list will do.

I don't seem to be able to provide coherent, objective arguments, at
least beyond the ones you might find at Smalltalk.org or Squeak.org.

Here's an entirely subjective opinion after over twenty years of
programming.

Among others, I learned Python and Smalltalk in the last year. I didn't
particularly like Python for the first three or four weeks before it began
to grow on me. It wasn't exactly what I was used to and it took me some
time to discover its strengths.

Contrarily, it took me no more than a day or two to really like the
Smalltalk language and its environment. After a few weeks, I was
quite surprised at the environment's capabilities: I discovered I was
doing some things I didn't realize any environment could do. I hadn't
read about them or done more than a little experimentation, they just
seemed natural. For example, it's trivially easy to stop a program's
execute, view and fiddle about with objects and code, and then continue on.

My conclusion, for what little it's worth, was "This is the way it was
intended to be."