New to Python: Features

[Andrew Dalke]

Alex Martelli wrote:
> It doesn't distinguish whether code X you wrote yourself or got from
> Mario, but... why would you care?  If you did, surely a workspace
> concept could be built on top of some modern versioning system such as
> SVN to let you do the equivalent of a 'svn blame' -- but, again, this
> feels to me as a conflating of orthogonal concerns.

Because the new version of the system might be incompatible
at the lower depths.  If I added a new function to system
code and the new version of the system also adds a function
with same name and signature, then who wins?  If the system
requires certain behavior from that function and my function
doesn't do it, the workspace can freeze.

So I'm told by a friend of mine who manages to freeze his
Squeak by, for example, messing around with how the call
stack objects work.  To get out of it, he just uses an
older image.  Rather like a savegame.

It seems that to prevent this the import and/or export
mechanism must have some way to help identify which
functions are normal and which are likely to cause system
problems.

Again, my viewpoint is completely detached from any
practical experience.

> In Python, you can pretty easily define a type X such that instantiating
> X with an argument of 23 (only) results in a reload of all your
> currently reloaded modules plus an email to foo at aleax.it giving your
> system's uptime.

True.   Should be on its way.  Reloading modules was the hard
part.  Needed to check that isinstance(module, types.ModuleType)
and that the module name != "__main__".  ;)

> So would Python plus a rebinding of __builtins__.hex to the above class
> X.  So?  What's your point?

That the word 'horror' means something different for you
than for me.

> Yeah, looks like a cool idea, but Ruby experts tell me it's never really
> practically useful... much like, say, double-leading-underscores names
> in Python classes -- neat idea, but not used in best practice anyway.

Hmm.  I'll bear that in mind.

One of the things I liked about C++ was constness of
objects.  And one of the things I didn't like was all
the extra work needed to make a library const safe.

I've at times wanted something like that in Python, as
when I have one attribute which depends on the data in
another.  Were one to be changed without the other
there would be an integrity problem.  But I know the
right Python way to solve that problem if the "we're
all adults here" solution isn't enough.


> Mine too (just started my 50th year -- it's 23 minutes after the end of
> my 49th b'day, local time), that's part of why google's SO useful;-).


Buon Compleanno!


(Or should I say  ¡Buon Compleanno! as you wish Italian to be :)

				Andrew
				dalke at dalkescientific.com