New to Python: Features

[Alex Martelli]

Andrew Dalke <adalke at mindspring.com> wrote:
   ...
> 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.

And that was basically what an APL (or APL2?) workspace let me do
(except it was more often to get to another machine, not to upgrade
versions of the system, but, no big difference).  Whether the
"personalized version" is one you've written yourself or got on a pack
of cards from your friend Mario is no big deal here, they're both
additions you'll likely want in your new workspace anyway.

APL didn't let me hack internals any more than Python does -- and Ruby
doesn't have workspaces any more than Python does... the idea of having
workspaces (restorable saves of your interactive sessions &c) and that
of hacking internals are surely orthogonal, I'm not sure why you're
conflating the two.

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

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.


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

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.  I would consider taking advantage of such possibility
a horror on the part of the programmer thus miscoding.  I do not
consider it a horror on Python's part to allow it, as the checks and
prohibitions needed to forbid such silliness would be cumbersome and
unwarranted.  And I don't think the distinction is all that subtle,
either.

> all my language "Al2O3", which is Ruby plus that dozen
> or so line patch for string coercion, seems to fit into
> your horror category.

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


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

print>>bah,'eek' is a bletch whether in production or just horsing
around -- that's different!-)

> Ruby has a way to freeze objects, so they cannot be changed.

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.

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

<shrug> easy enough to un-freeze frozen objects.  Having them start
frozen might avoid some accident but I don't think such accidents are
really that much of a concern in this context.

> Sadly my unassisted memory grows rusted.  I was confusing

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

> 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

Yep, a completely different issue from what goes on the right of a %.
Similar in being about Python not forbidding something though it isn't
to be used 99.9% of the time, much like modifying built-ins;-).


Alex