New to Python: Features

[Alex Martelli]

Andrew Dalke <adalke at mindspring.com> wrote:

> Alex [on tail call elimination]:
> > My use case for this was
> > the nightmare of 'recursion limits exceeded' for a nevow page with a few
> > hundred deferreds -- they got (implicitly, by the framework) chained to
> > each other by tail call (for termination purposes), 
> 
> Don't know enough about Nevow to comment.  Someone else
> pointed out an existing bytecode hack to support this
> so you might not need to wait.

Sure, there _are_ possible workarounds, as I've said.  I do believe it
might be nice, though, if a standard way existed (e.g. a decorator) to
express "the following function/method need not keep tracebacks but
rather should optimize tail calls", so that each framework or whatever
need not reinvent it.


> > I was very used to workspaces back in the days of APL and I still miss
> > them.  Why is it good not to have them?
> 
> I've never used such a system so this is only second hand.
> I recall hearing that in Smalltalk people end up customizing
> an image, which makes is harder for different people to work
> together on the same project.

As I recall, in IBM Research we tended to share a common workspace
across one project, though each of us could and generally did have their
own 'sandbox' workspace ``hived off'' the main one -- not very different
from the situation with any typical CVS / SVN / etc - controlled project
(though, if my memory serves, the workspace functionalities were skimpy
compared to today's typical versioning systems -- in terms of branching,
tagging, and other advanced stuff).  Imports/exports of sources for some
part of the workspace were commonly used; few of us had at home either
computers or terminals capable of good APL work (really needed a special
keyboard...), so a typical way to work evenings or weekends without
bothering to drive to the office would be to export some subtree of
sources, print it out (with a good APL-capable printer;-), and work with
a pencil on the printout.  Not very different from what one could do
with file, really; but in addition the workspace automatically kept
track of interactive sessions, with the ability to restart right from
where you left off, and also to export enough source code
_automatically_ to reconstruct the current situation somewhere else.

I have less experience of Smalltalk since I've never worked on "real"
group projects with it, but I'm sure its functionalities cannot be
lesser than what APL offered 20 years ago in its workspaces (maybe it
was already APL2 by that time... I'm not entirely sure, IBM Research
sometimes used such products internally before they were released).


> I think of it as working on a Python installation where
> I've installed more and more packages over time so when
> I start working with a new Python (working on a new
> machine, or upgrading to 2.4) I've got to reinstall
> everything to get my software to work again.  Only worse
> because in a workspace there might not be an independent
> source for a function I hacked together months ago
> that I end up using often.

Part of a workspace's functionality had better be that to emit sources
(for some or all of the stuff in the workspace) out to some text file,
which can later be loaded into some other workspace (on a new machine,
or after a version upgrade, etc).  Since at any time you can fire up an
editor on 'function so and so' (and I'm sure this holds for both APL and
Smalltalk), clearly the workspace must keep the sources, or be able to
reconstruct them rapidly on demand if what it does keep is some sort of
AST or whatever; dumping the sources out to a textfile and reloading
them from there thus shouldn't be too hard (and some selectivity, e.g.
"do you also want the dependencies or not" &c, should also be easy).

Of course not all Python objects will be properly serializable (to
source or to any other form) -- open files and open network connections
for example can hardly be 'frozen' and reconstituted at will, at least
in the general case.  But just as this doesn't stop us from having
pickle for that 90%+ of objects that CAN be serialized, it shouldn't
stop us from having workspaces, I think.


> >>Try Perl or Ruby instead.
> > 
> > 
> > Not Ruby!  That's a _good_ language:
> > 
> > kallisti:~/cb/cha/tex/cba alex$ ruby         
> > 2+"23"
> > -:1:in `+': String can't be coerced into Fixnum (TypeError)
> >         from -:1
>  >
> > to perpetrate such horrors, he definitely wants Perl.
> 
> Methods of builtin types can be changed in Ruby.  To

True, as I also pointed out later.

> Personally I think the ability to do this is a horror,
> precisely because it leads to the horrors you talk about.

I wouldn't go so far as to call it a horror.  I do consider it an excess
of power/dynamism, which I'd rather not have in a language intended for
production use.

> > Not sure what docs (besides Python Cookbook and Python in a Nutshell)
> > one would have to read to find this answer -- differently from most
> > other questions he's asking, this one's hardly obvious from docs...
> 
> And I think I pointed it out to you in c.l.py 3 or 4
> years ago ;)

Google Groups to the rescue...: I do see a post from you mentioning the
idea, in late 2000, but it is in response to Raymond Hettinger, not to
me; Raymond was asking for "any mapping to be accepted on the right of a
% formatting operator" as a Python enhancement, and you pointed out that
the time machine had beaten him to it and mentioned using that
possibility in a docstring-formatting package you had written.

I was also involved in the same thread, discussing other aspects of
Raymond's wishlist, and it seems clear that I wasn't familiar with the
idea, at the time, because I didn't tell RH, in my responses, that it
would already work.  It does seem reasonable, therefore, to assume that
I got the idea from reading your response to Raymond -- though it was to
him, not to me, that you pointed it out;-).

Heh -- Googling for posts to c.l.py in that timeframe always points me
to my posts of a year before, where, identifying as a Python newbie, I
had the gall to point out that Python needed a way to overload 'in' (the
__contains__ method was already planned but I didn't know... I happened
to propose exactly the same special name though!-) and have any object
return an iterator (I called it an "enumerator" instead, and proposed
methods __enum__ and __advance__, while now they're called __iter__ and
next, of course).  Gotta reread that one once in a while to refresh my
patience towards newbies with the gall to propose changes to Python;-).

 
> > I agree with you that it does, though not as well as you appear to
> > believe (e.g. no `` 2 + "23" '' abominations in Ruby, either).
> 
> Unless one wants it.  That's why I think Ruby is a better fit
> for the OP -- it lets him change the language much more to
> meet his expectations than Python does.

Yes, this may indeed be an important point.


Alex