New to Python: Features

[Andrew Dalke]

Alex Martelli wrote:
> 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.

Mmm, I read your reply to mean you thought such a bytecode
hack might some day be written, not that that it does exist.
On rereading I see you did not say that.

>> 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).

By "independent source" I meant to distinguish between
a external package that I installed and code the I wrote myself.
My thought, unbacked by practical experience, is that
on upgrades I would need to find all my own personalized
functions, export them, and import them into the new system.

If it's an external package that's easy.  I installed it
from source in the first place.  For my own code there isn't
such a source.  Do the environments let me find all
my personal modifications to the default?  If I did something
like modify integer so int + string automatically coerces
string into in, would it also export those system level
modifications?



> 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).

While related to my statement, that's not what I was hoping
to discuss.  Perhaps a restatement to make things clearer?

Upgrading Python versions is tedious, but at least it's
easy to find all my modifications to the install.  They
can be found in files and subdirectories in the PYTHONPATH.
None of my changes affect the "system" part of Python.
I don't stick code in the top-level of
/usr/local/lib/python2.3 nor do I write code that changes
the behavior of core objects.  I don't add 'sqrt' as a
method to numbers, nor let + work between numbers and
strings.

Python does not support the latter behavior, although
Ruby does.  In Ruby's case it's implemented by starting
with the pristine image then making changes, represented
as files.

The workspace approach does something different, in
my mind.  There is no concise set of deltas to know
how to go from the pristine image to the customized
one.  So if I did upgrade the system behavior, and
I get the feel that that's not unusual, then how does
the workspace figure out how to produce source that
can be passed to a new, pristine workspace and get
my personal customizations working again?

To my understanding it either saves the full image,
or it saves code you've selected.  How does it help
identifing all of the code that's relevant for this
sort of upgrade?

Though I mean that hypothetically.  I'm almost never
customize my environment.  My .cshrc defines three
aliases, I've not customized my .emacs, etc.

>>Methods of builtin types can be changed in Ruby.  To
> 
> 
> True, as I also pointed out later.

That must have been after I went to bed.  ;)

>>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.

I'm having a difficult time understanding when you would
use the word horror vs. when not.  Wouldn't it be okay to
have " 4 + '5' " produce 9 in a language not intended for
production use?  It seems there is a sensitive threshold
between your 'good language' and one with 'horror'.  After
all my language "Al2O3", which is Ruby plus that dozen
or so line patch for string coercion, seems to fit into
your horror category.

Ahh, but then you're one who used 'horror' when describing
the "print >>" syntax so "horror", "production use", and
"good language" are not independent terms.  ;)

Ruby has a way to freeze objects, so they cannot be changed.
In my view of things I would have had the system objects
frozen so that they cannot be changed, so that like in
Python system class behavior only 'modifiable' through
subclassing.

That would have left the power/dynamism available, but in
such a way as to moderate its impact.

>>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;

Sadly my unassisted memory grows rusted.  I was confusing
that with another part of the same thread where I pointed out
to you

 >>   proxy = Proxy(...)
 >>   sys.modules[module_name] = proxy
 >>
 >> In other words, what you import doesn't need to be a module.
 >> It can be a class instance instead - or any other data type.

and you replied
 > Now THAT is interesting!  I would never have guessed that the
 > items in sys.modules need not be module objects.  Is this


				Andrew
				dalke at dalkescientific.com